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ABSTRACT 


This  document  report*  the  finding*  of  *  study  of  alter¬ 
native  system  architecture*  for  secure  database  management 
systems*  System  requirements  are  stated  and  the  relation  to 
operating  system  security  1*  discussed*  Security  kernels* 
their  history  as  well  as  their  advantages  and  problems)  are 
described*  Additional  security  requirements  for  database 
systems  are  Introduced  and  some  models  and  experimental  sys¬ 
tems  are  reviewed*  representing  non— a rchi tectural  and  archi¬ 
tectural  approaches  to  non— secure  and  secure  database  sys¬ 
tems*  Conclusions  and  evaluations  are  made  throughout*  It 
is  also  suggested  that  military  planners  and  system  desig¬ 
ners  re— evaluate  their  traditional  approaches  to  security 
policy(  in  order  to  take  advantage  of  emerging  technology* 
Broad— based  recommendations  are  then  made  as  a  baseline  for 
determining  appropriate  research  directions  In  the  area  of 
data  security. 
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1.  INTRODUCTION 


1*1  Goals  of  the  Projact 


Tha  objectives  for  this  study  were  written  In  the 

Request  for  Short  Term  Analysis  Service  (STAS)  as  follows! 

Tha  objective  of  this  requlreaent  is  to  Investigate 
alternative  systea  architectures  for  secure  Database 
Management  Systems.  Appropriate  analysis  Is  to 
include  recent  approaches  such  as  back-end  compu¬ 
ters*  database  machines*  networks*  and  distributed 
databases  and  Multiprocessor  architectures.  Each 
approach  should  be  studied  for  feasibility*  relative 
advantages  and  drawbacks*  range  of  policies  lmple— 
mentable  by  mechanisms  provided*  cost*  and  perfor¬ 
mance.  The  results  of  this  study  will  produce  a 
baseline  for  determining  appropriate  research  direc¬ 
tions  in  the  area  of  security. 


As  the  work  progressed*  It  became  increasingly  clear 

that: 

1)  Owing  to  the  state-of— the— art  nature  of  the  subject* 

insufficient  detail  exists  to  allow  for  analysis  of 

cost  and  performance*  and  for  slgnlcant  cost  compari¬ 
sons  to  be  made. 

2)  Direct  comparisons  of  the  (  various  alternatives  and 

approaches  was  rendered  Inapplicable  because  of  the 
varying  stages  of  development  of  the  approaches.  A 
second*  more  Important*  reason  is  that  fundaaental  dif¬ 
ferences  In  approach  tend  to  invalidate  direct  compari¬ 
sons  because  they  are  comparisons  of  "apples  and 

oranges. " 

As  a  result*  through  telephone  conversations  with  peo¬ 
ple  at  AIRMICS*  the  COTR  organization*  the  objectives  of  the 
work  have  evolved  to  deemphaslze  quantitative  analysis* 
while  the  main  thrust  of  the  study  has  remained  the  same.  A 
statement  of  specific  goals  used  as  a  guide  for  interpreting 
and  achieving  the  stated  objectives  is  es  follows! 
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1)  Collect  information  as  comprehensively  as  pQS^bl*  fro* 
military*  academic*  and  commercial  sources* 

2)  Report  findings  of  1)  above* 

3)  Make  broad— based  recommendations  about  whictg  general 
directions  appear  most  promising* 

4)  Provide  Information  and  advice  with  which  military 
planners  and  system  designers  can  reconsider  their 
traditional  approach  and  be  prepared  to  take  advantage 
of  new  developments  in  the  state— of— the— art* 

5)  Attempt*  whenever  possible*  to  use  up— to— the— minute 
results  to  assist  in  achieving  an  awareness  of  alterna¬ 
tives  necessary  In  reaching  goal  4)  above* 

In  several  cases  there  was  a  minor  difficulty  with  S) 
above*  in  that  security  restrictions  presented  barriers  to 
obtaining  the  necessary  information*  This  was  particularly 
true  with  military  organizations  and  their  contractors 
(e*g**  DCA*  SDC*  I*  P*  Sharpe)*  In  other  cases,  with  aca¬ 
demic  and  industrial  sources*  very  current  information  was 
obtained,  including  descriptions  of  work  in  progress  but  not 
yet  published*  A  personal  approach  to  information  gathering 
made  use  of  letters  and  follow-up  telephone  calls*  Also* 
personal  participation  'la  the  planning  and  execution  of  an 
Army  Automation  Security  Workshop  was  helpful  to  the  author 
in  identifying*  and  relating  thin  project  to*  Army  needs* 


1*2  Scope  of  Project 


This  section  briefly  delimits  the  type  of  security  to 
be  discussed,  except  for  a  short  mention  of  some  of  the 
"peripheral  issues"  in  section  5*2*  The  focus  of  the  work 
Is  oi.  secure  database  management*  The  security  of  operating 
systems  is  addressed  only  in  that  it  relates  to  that  of 
database  systems*  The  scope  specifically  excludes  topics 


such  as  personal  identification*  physical  access  controls  to 
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computer  facilities*  and  cryptography*  thlle  these  are 
Interesting  and  necessary  parts  of  an  overall  secure  opera¬ 
tion*  they  are  not  in  the  objectives  of  this  study*  These 
topics  are  being  studied  by  others*  each  as  a  separate  field 
of  Interest* 


1*3  Terminology 


This  section  will  serve  to  define  some  of  the  terminol¬ 
ogy  that  the  reader  may  encounter  In  this  and  other  litera¬ 
ture  on  the  subject*  Some  of  the  definitions  are  a  bl t 

arbitrary  In  that  no  standard  definitions  have  yet  been 
established*  (Also*  some  of  these  definitions— e*g«* 

integrity—— are  not  quite  the  same  as  those  found  in  AR 
380—380  CAR1IYR771*  but  they  are  consistent  elth  the  litera¬ 
ture*  I 

Protect  ion — The  preservation  against  unauthorized  use  of 
computing  resources*  especially  the  protection  of  data 
from  accidental  or  deliberate  disclosure  or  modifica¬ 
tion*  Protection  Includes  security*  privacy*  and  Integ¬ 
rity  concerns* 

Security— —The  protection  against  deliberate  disclosure  or 
modification  of  data  In  cases  involving  national 
defense*  Security  also  covers  cases  involving  Indus¬ 
trial  economics  (e*g**  industrial  spies)  and  commercial 
finances  (e*g**  fraud)* 

Privacy — Protection  of  data  about  people;  in  particular* 
the  protection  of  the  legal  rights  of  individuals  and 
organizations  to  self  determination  of  the  degree  to 
which  information  about  themselves  can  be  collected* 
stored*  and  shared  with  other  individuals  and  organiza¬ 
tions*  Privacy  includes  confidentiality*  which  is  the 
protection  of  Individual  anonymity  while  globally  pro¬ 
cessing  ( e* g* *  gathering  statistics)  data  about  people* 
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Integrity — Operational  integrity  Is  the  protection  o t  the 
logical  consistency  of  data  by  properly  synchronizing 
accesses  that  modify  data*  Semantic  Integrity  is  the 
protection  of  the  logical  consistency  of  dat a  by  check¬ 
ing  all  inputs  and  updates  against  specified  const¬ 
raints.  (This  Is  different  from  the  AR380-380  [AKMYK77] 
definition  of  integrity  which  refers  to  it  in  terms  of 
overall  system  security  as!  "The  capability  of  an  ABF 
system  to  perform  its  intended  function  in  an  unimpaired 
manner*  free  from  deliberate  or'  inadvertent  unauthorized 
manipulation  of  the  system*") 

Protection  pol teles — Policies  are  the  rules  of  access  to 
computing  resources* 

Protection  mechanisms— Mechanisms  are  the  means  to  imple¬ 
menting  policies  within  a  given  protection  system*  A 
security  system  may  be  viewed  as  having  a  "pool"  from 
which  mechanisms  may  be  selected  and  combined  to  imple¬ 
ment  any  given  policy*  As  an  analogy*  the  basic 

Instruction  set  of  a  computer  provides  mechanisms  to  be 
put  together  to  form  programs  which  execute  policies* 
When  policy  is  built  into  mechanism*  it  should  be  done 
del iberatcly*  with  a  conscious  appreciation  for  the 
tradeoff  being  ma^e  of  flexibility  for  economy* 


1*4  System  Requirements 


This  section  describes  a  number  of  protection  features 
which  are  useful  or  necessary  in  a  forward-looking  secure 
military  data  management  system*  Many  of  these  requirements 
will  be  referred  to  by  name  later  in  the  report* 

1)  Multilevel  protect  ion— In  a  military  system*  this  tern 
often  means  that  more  than  one  security  classification 
level  can  exist  together  within  the  system*  In  other 


contexts*  the  term  has  been  used  to  refer  to  protection 
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mechanisms  which  occur  at  more  than  ona  level  of  soft¬ 
ware  and  hardware*  The  term  also  can  Imply  that  pro¬ 
tection  checkins  can  be  done  at  several  levels  (granu¬ 
larities)  of  data  (e*g*,  system,  file,  record  type, 
record  Instance,  field)* 

2)  No  "back  doors" — All  data  Is  accessed  via  a  common 
entry  point  to  the  DBMS*  Hidden  entries  are  guaranteed 
not  to  exist* 

3)  Decentralized  aut ho rl za t Ion- — Pe rmlsslon  to  grant  access 
privileges  exists  among  many  different  authorities, 
each  of  which  has  security  responsibilities  for  differ¬ 
ent,  possibly  overlapping,  parts  of  the  database*  This 
feature  Is  useful  In  eliminating  the  operational  bot¬ 
tlenecks  found  with  a  centralized  database  administra¬ 
tor  (DBA),  but  it  complicates  the  authorization  pro¬ 
grams  considerably  and  requires  the  concept  of  resource 
"ownership"  to  be  Implemented*  An  owner  is  one  who  can 
propagate  access  rights  to  a  given  resource*  Propaga¬ 
tion  of  ownership  brings  about  the  problem  of  access 
privilege  revocation  (GRIFP76I,  a  problem  without  an 
automated  solution*  Of  course,  decentralized  authori¬ 
zation  requires  discretionary  controls  (not  a  system 
based  on  Just  security  levels)* 

4)  Reasonable  performance — Security  has  its  cost  In  over¬ 
head  of  processing  and  storage*  Performance  penalties 
must  be  limited  to  a  reasonable  percentage* 

5)  Uniformity  of  mechanisms — One  general  protection 

mechanism,  uniformly  applied,  is  safer  than  a  static 
mechanism  requiring  the  handling  of  many  exceptions 
(CLAYB781*  The  same  mechanisms  should  be  used,  regard¬ 
less  of  the  purpose  of  the  protection;  for  e«g*,  secur¬ 
ity,  privacy,  and  integrity  should  be  leplemented  with 
a  common  net  of  mechanisms* 
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71  Integrated  secu r i ty— — Pr o tec t ion  nechanlaas  are  to  bo 
Integrated  into  the  heart  of  tho  system  architecture 
from  the  start  and  not  "added  on"  to  existing  database 
synteesa  Many  early  system  design  decisions  must  take 
security  requirements  Into  account*  Without  security 
requirements*  these  decisions  will  be  made  In  a  differ¬ 
ent  way*  In  favor  of  other  factors  (primarily  In  favor 
of  performance)* 

8)  Improved  protection  precision — Fixed  unsophisticated 
protection  mechanisms  have  been  limited  In  their  abil¬ 
ity  to  adhere  with  precision  to  the  increasingly  com¬ 
plex  policies  of  the  database  environment*  This  Impre¬ 
cision  causes  access  decision  errors  ( HARTH77 1 • 

9)  Dynamic  authorization — Authorlzers  have  the  ability  to 

change  access  rights  interactively  while  the  DBMS  Is 
operational*  This  is  becoming  a  requirement  for  any 
on— line  DBMS*  It  is  also  useful  in  supporting  the 

"need— to— know"  principle* 

10)  Kernels - Kernels  and  methodological  aids  to  verifying 

system  security  are  necessary*  in  combination  with 
rigorous  software  testing* 

11)  Cooperative  aut ho,r lza t ion— As  a  natural  consequence  of 
decentralized  authorization*  authorization  from  sev¬ 
eral  cooperating  authorities  [MINSN77]  might  be 
required  for  certain  highly  sensitive  operations* 

12)  Generalized  and  distributed  data — Generalized  DBMS  are 
required  for  the  operations  addressed  in  this  report; 
simple  file  management  operations  offered  by  typical 
operating  systems  are  not  adequate*  (n  many  cases  the 
data  (and  DBMS)  will  be  distributed  within  a  network 
of  systems. 

13)  Protection  languagee — An  easy-to-use  interface  is 
necessary  to  allow  authorizations  to  be  made  correctly 
and  In  a  timely  manner* 


Protection  languages 
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requested  date  is  authorized  for  access*  The  level  of 
granularity  with  which  enforcement  sechanlsas  can  deal 
in  such  cases  (for  example*  partial  access  vs*  *fi«t 
yes  or  no"  decision)  is  a  question  of  "resolution  of 
enforcement"  (HABTH77J*  If  policies  allow  for  partial 
access*  mechanisms  will  need  to  have  the  ability  to 
filter  out  the  unauthorized  portion  from  the  author¬ 
ized  portion  of  requested  data* 

15)  Rang*  of  access  decision  dependency— in  general* 
enforcement  decisions  need  to  be  based  on  many  varia¬ 
bles*  The  degree  to  which  protection  mechanisms  are 
sensitive  to  these  variables  determines  the  range  of 
policies  lmplementable  by  those  mechanisms* 

a)  data  names  and  types  (data  definition  dependency) 

b)  data  values  within  the  data  being  retrieved 

c)  data  values  elsewhere  in  the  database 

d)  input  data  values  (integrity  constraints  for  inser¬ 
tion  and  modification) 

e)  system  state  variables  (e.g**  time  of  day* 

switches*  modes  of  processing*  status  Indicators* 
etc*) 

f)  user  related  Information  (e*g**  user  ID*  re— authen¬ 
tication  results*  terminal*  time  of  login*  etc*) 

g)  access  history  information 

h)  results  of  procedural  protection  measures  "trig¬ 
gered"  by  the  access  request 

16)  Exception  reporting - In  real  systems*  mechanisms  are 

needed  for  handling  and  reporting  exceptions*  This 
Includes  an  ability  to  produce  Journal  flies*  protec¬ 
tion  logs*  and  audit  trails*  It  also  includes  the 
ability  to  handle  and  report  penetration  attempts 
(accidental  or  deliberate)  without  greatly  affecting 
the  performance  of  normal  operations* 


2.  RELATION  TO  OPESATI NC  SYSTEM  SHCb ilTY 


2. 1  Introduction 

While  the  security  of  operating  system*  Is  not  directly 
pert  of  database  protection!  the  close  and  complex  relation¬ 
ship  between  operating  systems  (OS's)  and  database  manage¬ 
ment  systems  (DBMS's)  warrants  the  consideration  of  OS 
security  In  this  report*  Indeed,  many  of  the  functions  pro¬ 
vided  by  OS's  («•(••  low  level  Input/output,  resource  Inter¬ 
locking  for  shared  usage,  etc*)  are  critical  to  DBMS  opera¬ 
tions.  With  vulnerable  OS  functions,  secure  DBMS  are  of 
little  use  in  overall  system  security*  As  this  section  con¬ 
centrates  on  recent  work  in  the  area  of  security  kernels, 
the  reader  Is  referred  to  the  literature  for  a  more  compre¬ 
hensive  discussion  of  OS  security  [ SALTJ75,  HABKM75, 
JONBA75,  etc.]. 

2.2  Security  Kernels — What  They  Are  and  Are  Not 

The  testing  of  large  nodules  of  software  has  been  shown 
to  be  insufficient,  by  itself,  for  demonstrating  that  the 
software  is  secure  (ANDEJ721*  On  the  other  hand,  thorough 
software  testing  has  certainly  been  shown  to  play  an  impor¬ 
tant  role.  (See  Tanenbaum  (TANEA76)  for  an  amusing,  but 
realistic  discussion  of  this  viewpoint.)  In  fact,  a  two 
step  system  certification  procedure,  as  a  combination  of 
verification  and  installation  review  and  testing  has  bsen 
suggested  for  military  computer  security  IWALKS77). 
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The  difficulty  of  verifying  large  systems  of  software 
has  led  to  the  concept  of  security  kernels  Into  which  all 
security  related  software  Is  to  be  concentrated  Into  a 
smaller*  certifiable  protected  nucleus*  separata  froa  the 
rest  of  the  OS  functions*  Non— kernel  OS  software  can  then 
be  allowed  to  run  In  an  unprotected  environment*  As  aost  of 
the  recent  work  In  kernel  laplementatlon  has  shown  (MILLJ76* 
l'OPEG78a*  POPEG78b)  kernels  have  gone  a  long  way  toward 
reaching  this  goal*  A  kernel— based  approach  forces  the  sys¬ 
tem  software  to  be  very  well  structured  and  to  be  highly 
transparent  (straightforward*  readable*  and  easy  to  under¬ 
stand  without  following  "clever"  gyrations  within  the  code)* 
This  structure*  though  perhaps  achieved  at  a  slight  cost  In 
performance*  has  increased  the  level  of  confidence  of  OS 
security  greatly  over  that  of  the  previous  generation  of 
flaw— ridden*  overly  complex  patchworks  of  software* 

But  kernels*  an  the  literature  has  not  been  quick  to 
point  out*  still  do  not  guarantee  security.  The  proof  of  a 
program  Is  not  a  guarantee  of  its  reliability  [ TANEA76 ]* 
Furthermore*  proving  individual  programs  is  not  the  same  as 
proving  a  system  of  Interacting  programs*  It  is  also  diffi¬ 
cult  to  prove  that  all  necessary  code  is  in  the  kernel* 
This  requires  proving  something  about  the  entire  system  of 
software*  and  one  reason  for  having  a  kernel  Is  the  diffi¬ 
culty  of  proving  things  about  the  entire  system*  Further* 
it  is  a  reality  (at  least  within  current  state— of— the— art) 
that  some  security  related  software  must  remain  outside  the 
kernel*  If  its  bulk  Is  to  remain  within  reasonable  limits* 
Software  for  resource  management  and  physical  device  support 
Is  typically  among  the  outcast  code  that*  In  fact*  Is  sensi¬ 
tive  to  security  flaws*  Sometimes  this  rsquires  "trusted" 
non— kernel  software  (P0PB078a]*  which  leads  to  various  lev¬ 
els  of  kernels*  It  Is  part  of  tbs  "bowl  of  spaghetti"  syn¬ 
drome*  a  term  coined  within  the  MULTI SAFB  project  (MULTI  SAFE 
Is  discussed  In  section  4*4*2)*  As  one  attempts  to  sepe— 
rets*  with  each  bite*  an  amount  that  can  be  reaeonably  hen— 


to 
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died,  the  complex  Interconnection*  caitte  more  and  more  spa¬ 
ghetti  to  be  pulled  from  the  bowl*  I Ithln  the  MULTISAFE 
project  the  operational  definition  of  the  Ideal  kernel  Is 
"that  minimal  collection  of  software  each  that  no  fault  or 
subversion  of  other  software  can  cauee  security  to  be  con— 
promised***  However*  as  a  practical  setter*  the  bowl  of  spa¬ 
ghetti  syndrome  require*  that  a  considerable  quantity  of 
security  software  to  be  outside  the  kernel*  in  all  systems 
this  non— kernel  software  can  have  an  Impact  on  security*  An 
Important  way  that  subverted  non— kernel  software  can  com¬ 
promise  security  Is  by  passing  falsa  Information  to  the  ker¬ 
nel*  If  false  parameters  are  accepted  by  the  kernel*  unau¬ 
thorized  accesses  could  be  allowed  by  an  otherwise  perfect 
and  proven  kernel*  For  example*  a  subverted  (or  subversive) 
DBMS  might  **110*  about  the  natur*  of  the  data  It  is  trying 
to  pass  through  security  checks  back  to  the  user* 

It  has  also  been  suggested  that  non— kernel  software  be 
allowed  to  do  much  of  the  work  of  a  given  function  and  then 
have  the  kernel  check  the  final  results*  In  some  cases* 
this  Is  a  reasonable  way  to  reduce  kernel  bulk*  However* 
the  thorough  checking  of  some  processes  implies  a  checking 
c>f  how  the  results  were  obtained*  In  these  cases*  checking 
can  require  the  ability  to  reproduce  or  emulate  the  procesn 
being  checked — not  a  condition  allowing  for  substantially 
less  volume  in  software  than  that  of  tbe  process  (being 
checkedl  itself* 

Improved  hardware  and  firmware  support  (see  [POPBC78a] 
for  examples)  offers  hope  for  even  more  secure  and  more  c on— 
pact  kernels  In  the  future*  Improved  methodology  ( BOBVL77 J 
offers  hop*  for  nor*  secure  overall  systems* 
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2.3. t  Background 
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Over  aoat  of  the  past  decade  several  project*  have  con¬ 
tributed  to  the  present  technology  of  secure  OS.  Starting 
In  about  1968,  penetration  efforts  of  "tiger  teams"  revealed 
the  appalling  state  of  security  in  operating  systems.  More 
Importantly,  those  tests  shoved  that  finding  and  patching  of 
security  leaks  was  not  a  viable  approach.  Penetrators  never 
failed  to  find  more  holes  and  errors.  Andt  even  if  more 
could  not  be  found*  their  non-existence  could  not  be  proved. 

Designers  vould  be  required  to  start  over  from  scratch,  to 
design  and  develop  operating  systems  in  a  nes,  highly  rigo¬ 
rous  and  systematic  way.  Early  research  (circa  1972)  spon¬ 
sored  by  the  Electronic  Systems  Division  of  the  Air  Force 
yielded  the  concept  of  the  reference  monitor  which  performs 
complete  mediation  of  every  memory  reference  (every  access). 

It  was  partly  from  this  work  that  the  kernel  concept  and  Its 
properties  of  isolation  and  correctness  were  derived.  Early 
llitre  modelling  (BELLD731  set  military  policy  (e.g.,  the 
star  property)  in  a  formal  mathematical  model. 

MULTICS,  developed  at  MIT  and  one  of  the  earliest 
security  oriented  systems  (SALTJ74),  was  not  based  on  for¬ 
malisms  for  verification  »•?  software.  It  has  been  subse¬ 
quently  adapted  by  Honeywell  as  Multlcs,  the  most  secure 
system  commercially  available.  It  also  has  been  kernellzed 
in  an  experimental  project  called  Guardian  within  a  combined 
effort  by  Honeywell  (HONEY76),  MIT  f  SCHRM77 ] ,  the  Air  Force, 
and  the  Stanford  Research  Institute  (using  SRI  methodology). 

Formal  specifications  were  developed,  but  not  implemented. 

Honeywell  developed  a  Secure  Communications  Processor 
(SCOMP)  [GILSJ751,  which  began  as  a  Honeywell  level  6  mini¬ 
computer-based  front-end  and  remote  communications  processor 
for  the  Guardian  secure  Multlcs  system.  As  such,  SCOMP  was 
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Module,  which  connected  to  the  system  hue  and  checked  all 
accesses  to  protected  objects*  Aftet  Guardian  was  terml— 
nated  In  1976,  work  on  SCOMP  continued,  and  It  developed 
Into  a  PDP-11  "look-alike"  (software  compatible)  with  a 
KSOS— like  (see  the  next  section)  secure— UNIX  operating  sys¬ 
tem*  SCOMP  is  sometimes  referred  to  as  "KSOS— 6*"  SCOMP 
uses  a  Mult lcs— like  ring  structure  to  implement  domains  of 
execution,  and  the  hardware  offers  a  significant  amount  of 
kernel  support*  Also  SDC  has  been  working  on  KVM,  a  kernel— 
ized  version  of  IBM  VM  370  (COLDB77  1.  KVM,  a  three  year 
project  which  began  in  1976,  will  guarantee  the  separation 
of  virtual  machines  in  VM/370,  removing  the  necessity  for 
periods  processing*  Virtual  machines  executing  processes  at 
different  classification  levels  may  reside  together  in  the 
same  system*  KVM  Is  targeted  for  use  in  DCA,  DCo«~,  and 
other  Intelligence  processing  sites*  Gerald  Popek 
{ POPGG78a,  POPEG78b]  has  developed  a  kernel  based,  verlfl— 
ably  secure  OS  at  UCLA  and  has  adapted  it  to  the  Bell  Labo¬ 
ratories*  UNIX  operating  system  for  the  PDP-11*  Mitre  has 
independently,  also  using  a  Kernel  approach,  produced  a 
secure  UNIX— like  OS  dedlgn* 

2*3*2  Kernel ized  Secure  Operating  System  (KSOS) 

The  Department  of  Defense  (DoD),  however,  needs  produc¬ 
tion  quality  systems,  which  are  the  next  logical  step  after 
these  "bread  board"  systems* 

In  1978,  the  Department  of  Defense  established  a  Compu¬ 
ter  Security  Initiative,  the  goal  of  which  is  to  achieve 
widespread  availability  of  secure  ADP  systems  within  the 
DoD*  Accomplishment  of  that  goal  will  depend  on  involvement 
of  computer  manufacturers  and  on  effective  mechanisms  for 
DoD  approval  of  secure  ADP  systems*  The  recent  DoD  direc¬ 
tive  (5200*28)  establishes  proper  channels,  technical  evalu¬ 
ation  procedures,  and  mechanisms  to  facilitate  solutions  to 
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this  latter  problem*  In  response  to  the  former*  the  DoD 
Computer  Securl ty  Technical  Consortium  (Stephen  Walker)  has 
funded  a  competitive  effort  (WALKS77)  to  produce  a  Kernel— 
lzed  Secure  OS  ( KSOS) •  The  Maturing  technology  from  the 
Initially  separate  efforts  described  above*  taking  place 
over  different  scales  of  times  and  with  varying  objectives* 
has  come  together  In  one  project*  It  Is  an  excellent  exam¬ 
ple  of  how  government  funding*  applied  at  the  proper  stage 
of  development*  can  provide  mutual  benefit  to  military  and 
private  enterprise  and  advance  the  stat e— of— the— art  at  the 
same  time*  As  a  result  of  this  experience  (with  KSOS)  a 
funding  policy  may  be  emerging:  the  government  appears  to 
be  willing  to  fund  original  design  and  Initial  implementa¬ 
tion*  but  not  successive  refinements  after  that* 

The  privilege  to  produce  the  DoD  production  quality 
kernel lzed  secure  OS  was  won  In  a  competitive  design  phase* 
over  TRW  by  Ford  Aerospace  (E*  J*  McCauley)*  with  SRI  (Peter 
Neumann)  as  a  subcontractor*  Gerald  Popek  of  UCLA  was  a 
consultant  to  TRW  for  part  of  their  work  and  Is  now  a  con¬ 
sultant  on  KSOS*  KSOS  was  presented  to  the  0*  S*  Army  Com¬ 
puter  Systems  Command  (USACSC)  at  a  Software  Symposium  In 
Williamsburg*  Virginia*  on  25—27  October  1978*  There  are 
also  several  papers  on  KSOS  being  prepared  for  the  1979 
National  Computer  Conference  (NCC)*  Among  the  DoD  partici¬ 
pants  are  the  Defense  Communications  Agency  (Ken  Moore* 
CCTC)  and  the  Army  (Ft*  Monmouth)*  The  main  spbnsor  is 
DARPA* 

The  goal  of  the  KSOS  project  Is  a  commercially  viable 
(production  quality)  secure  OS*  externally  compatible  with 
UNIX  and  Implemented  on  the  PDP— 11/70*  UNIX  Is  a  popular* 
straightforward  and  uncouples*  OS  for  the  PDP-11*  designed 
by  Bell  Laboratories  to  be  simple  and  efficient*  However* 
it  was  not  originally  designed  with  security  as  a  primary 
objective*  There  are  numerous  opportunities  for  "Trojan 
horses"  and  trap  doors  (NEUMP78)*  It  is  very  vulnerable 
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through  Its  "supsruaar"  slate.  The  goal  of  the  KSOS  effort 
Is  to  produce  a  secure  OS  with  the  good  features  of  UNIX  and 
with  comparable  operational  efficiency.  The  multilevel 
design  partitions  the  system  Into:  a  kernel*  trusted  non- 
kernel  security  related  software*  untrusted  non— kernel 
security  related  software*  and  an  emulator.  The  emulator 
provides  compatibility  with  an  existing  UNIX— like  user 
Interface  and  has  no  effect  on  security.  The  trusted  non- 
kernel  security  related  software  Is  partly  motivated  by  con¬ 
cerns  for  efficiency.  The  kernel  Is  actually  a  "complete*" 
small  operating  system  with  efficient  I/O  and  can  be  used  by 
Itself  in  a  dedicated  special  purpose  system  (e.g.*  secure 
communication  front— end).  Also*  other  (non— UNIX)  operating 
systems  can  be  built  upon  this  same  kernel. 

Phase  I  (of  KSOS) *  the  design  phase*  is  completed.  The 
design  exists  as  a  formal  specification*  and  Its  security 
properties  will  be  formally  verified.  In  Phase  II*  the 
Implementation  phase*  the  kernel  is  supposed  to  be  running 
by  Spring  1079  and  completed  by  the  following  Fall. 
Selected  parts  of  the  implementation  will  be  proved  to  be 
faithful  to  the  design.  Many  applications  are  being  planned 
and  developed  to  run  on  KSOS.  Of  interest  in  this  report  is 
a  secure  DBMS*  rumored  to,  be  like  Culllnine's  IDMS.  Others 
include  a  secure  network  front-end*  flexible  message  han¬ 
dlers*  and  the  Guard  system  described  In  section  2.3.5 

2.3.3  PSOS  and  the  HDM 

Peter  Neumann  (NEUMP77J  and  others  at  Slmnforti  Research 
Institute  ( SB I )  have  designed  a  Prorabl?  Secure  Operating 
System  (PSOS)  using  SBl*s  Hierarchical  Design  Methodology 
(HDM)  (ROBIL77).  It  Is  Interesting  that  PSOS  is  not  based 
on  the  kernel  concept.  This  makes  PSOS  more  general  than 
KSOS*  for  example*  In  that  PSOS  can  support  many  different 
security  policies*  not  necessarily  based  on  the  star— pro¬ 
perty.  It  also  more  easily  supports  discretionary  access 
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controls*  PSOS  uses  capabi 1 i ty— based  addressing  and  hard¬ 
ware  tagging  of  capabilities  to  insure  their  non— forgeabil¬ 
ity*  PSOS  is  not  implemented  yet*  One  of  the  problems  is 
that  existing  hardware  cannot  support  it*  It  is  hoped  that 
most  of  the  necessary  modifications  can  be  made  at  the  firm¬ 
ware  level*  The  Navy  1s  currently  Interested  In  developing 
a  PSOS  prototype* 

Perhaps  the  most  Important  aspect  of  tbe  PSOS  project 
is  the  Hierarchical  Design  Methodology*  used  In  the  design 
and  development  of  PSOS*  Based  on  the  fundamental  notion 
that  software  tools  are  the  most  Important  factor  In  achiev¬ 
ing  secure  systems*  HDM  provides  a  broad  range  of  tools 
allied  to  an  Integrated  methodology*  HDM  emphasizes  formal¬ 
ism  In  making  the  development  process  precise*  HDM  is  com¬ 
prehensive  In  that  It  applies  throughout  the  design  and 
development  process  of  a  system;  it  is  not  Just  about  pro¬ 
gram  proving*  As  such*  it  enhances  software  reliability  as 
well  as  security.  (Of  course*  one  cannot  really  believe  in 
the  security  of  an  unreliable  system*  anyway*)  HDM  concepts 
Include  hierarchical  decomposition*  structuring*  abstrac¬ 
tion*  modularity*  formAl  specification*  data  representation* 
and  program  verification*  HDM  mechanisms  Include  abstract 
machines  at  many  levels  (operations  and  internal  data  struc¬ 
tures)*  modules*  stages  of  development*  and  system  families* 
Among  HDM  languages  are  a  Hierarchical  Specification  Lan¬ 
guage*  a  SPECIf lcatlon  and  Assertion  Language  (SPECIAL)*  and 
an  Intermediate  Level  Programming  Language  (ILPL)*  SPECIAL 
allows  formal*  non— procedural  specifications  to  be  expressed 
in  a  predicate  calculus  form*  Programming  languages  for 
implementation  of  HDM  designed  systems  must  be  strongly 
typed*  have  no  aliases  of  objects*  and  do  no  hiding  of 
Implementation  details*  Several  modern  languages  such  as 
Modula*  Euclid*  Gypsy*  and  Ada  (nee  DoD/1) — all  variants  of 
PASCAL — are  possibilities*  but  each  has  its  own  drawbacks* 
ILPL  is  a  minimum  language  designed  to  Just  satisfy  HDM 
requirements* 
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UDM  development  stages  heftl  i  with  specification  of 
requirements  and,  then,  system  model  ins*  Next  are  design 
(yielding  specification  proofs)  and  Implementation  (yielding 
code  proofs)*  The  PSOS  project  plaii  is  to  verify  the  entire 
operating  system,  right  do*n  to  the  code  level*  The  dev*l- 
opment  process,  within  a  hierarchy  of  abstract  machines, 
builds  each  machine  by  writing  an  abstract  program  for  the 
functions  of  that  machine  in  terms  of  the  primitives  of  the 
next  lower  machine*  Within  PSOS,  for  example,  some  sixteen 
levels  of  abstraction  have  been  identified* 

A  detailed  example  of  this  methodology,  applied  to  a 
list  processing  problem,  is  given  in  {SP1TJ78I* 

There  are  other  languages  and  methodologies  which  have 
been  developed  independently  (for  example,  GYPST 

(AMBLA77)),  but  a  review  of  these  is  beyond  the  scope  of 
this  report. 

2*3*4  Unresolved  Issues 

The  state— of— the— art  is  sufficiently  undeveloped  so 
that  there  still  remains  a  difference  of  terminology  from 
one  group  of  researchers  to  another*  Single  definitions  for 
terms  such  as  trusted,  semi— trusted,  untrusted,  responsible, 
and  privileged  (as  applied  to  software  processes)  are  not 
universally  accepted*  Also,  a  difference  of  opinion  exists 
as  to  how  much  software  must  be  verified*  For  example, 
SRI's  approach  rcqqulres  verification  of  all  security 
related  software,  whether  or  not  it  is  in  the  kernel*  The 
author  believes,  along  with  the  SRI  people,  that  confidence 
in  any  approach  that  does  not  verify  all  security  related 
code  (such  as  appears  to  be  the  case  in  UCLA's  Secure  UNIX 
and  SUC* s  KVM)  cannot  be  complete* 

Some  of  the  trusted  software  of  KSOS  cannot  be  con¬ 
tained  in  the  kernel  because  it  (intentionally)  violates  the 
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security  axioms*  An  example  of  such  a  process  Is  ona 
Involving  declassification  or  "sanitization"  of  data*  In 
KSOS  these  processes  will  be  subjected  to  the  verification 
methodology  Just  the  same*  Those  procedures  will  point  out 
the  Intentional  "violations"  of  the  security  axioms*  but  no 
other  violations  will  be  allowed* 

On  the  other  hand*  the  KSOS  spooler  is  not  in  the  ker¬ 
nel*  either*  It  Is  In  a  grey  area  called  "respons lb le" 
software*  It  Is  not  directly  Involved  In  accessing  data* 
but  it  could  possibly  be  subverted  to  send  data  to  the  wrong 
peopl e* 

In  sum*  100%  secure  operating  systems  are  probably  not 
achievable*  However*  highly  secure  systems  are  attainable* 
and  such  systems  will  eventuallly  be  accredited  for  military 
use* 

2.3.5  Guard — A  KSOS  Application 

For  many  military  applications  there  is  a  growing  need 
to  be  able  to  Interconnect  many  computers*  often  several 
with  different  classification  levels*  The  passage  of  data 
from  high  to  low  levels  will  require  careful  sanitization 
and  declassification*  As  a  near-term  response  to  this  need* 
MITRE  and  the  Navy  (Navalei)  have  teamed  up  to  develop 
Guard*  a  semi— automated  system  which  acts  as  a  filter  bet¬ 
ween  two  computing  systems  operating  at  different  classifi¬ 
cation  levels*  Guard  runs  as  an  application  under  KSOS  on  a 
PDP-11*  The  sanitization  la  done  manually  In  a  high  classi¬ 
fication  environment  by  guard  officers*  A  security  watch 
officer  is  then  responsible  for  passing  the  data  to  the  low 
classification  environment*  In  a  network  such  as  the 
ARPANET*  the  Guard  system  might  be  called  upon  to  pass 
ARPANET  messages*  data  management  queries  {to  the  Datacompu— 
ter)*  and  data  responses*  Policy  requires  one  guard  officer 
per  high— dat abase/low— database  combination*  so  that  the 
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•ff leer  can  bacon*  familiar  with  th  t  particular  databases 
and  their  usage.  Roth  requests  and  Isaponsea  can  hs  edited 
by  the  guard  officer.  or  either  can  je  completely  rejected. 
Network  mall  between  different  cl  a :  » i f lea 1 1 on  levels  will 
also  pass  through  Guard.  Mall  Is  no'i  edited,  but  Is  checked 
by  the  security  watch  officer. 


2.4  Th*  Transition  to  Database  Management 


At  first  it  might  set m  that.  since  DBMS's  have  certain 
functions  in  common  with  OS's.  an  extension  of  OS  security 
principles  should  cover  database  security.  While  it  Is  true 
that  each  type  of  system  deals  with  sharing  of  structured 
data.  there  are  several  intrinsic  differences  which  asks 
DBMS's  much  more  than  an  extension  of  the  file  handling 
capabilities  of  present  day  OS's.  Correspondingly,  database 
security  is  not  Just  an  extension  of  OS  security.  Son*  of 
*  hose  differences  are  as  follows.  This  list  is  based  on  a 
list  developed  by  the  author  and  expanded  on  by  Fernandez  In 
[ FEDNE77 1  and  moat  of  the  items  are  taken  verbatim  from  that 
source! 

1)  Databases  need  a  finer  protection  granularity. 
Field-level  and  data— depends nt  control  are  required 
in  order  to  apply  a  need— to— know  policy  in  a  shared 
database  environment. 

2)  Databases  need  a  finer  granularity  for  aharing.  too. 
Therefore,  interlocking  for  shared  access  can  be  more 
difficult  (GRAYJ7S.  BAYEB76.  BIESD77). 

3)  In  shared  databases  there  is  a  large  number  of  data 
objects  with  cosplax  interrelationships  and  a  broad 
variety  of  data  types. 

4)  While  th*  OS  is  concerned  with  th*  nan*  and  address 
spaces  of  th*  data.  the  DBMS  is  also  concerned  with 
the  semantics  of  th*  data.  This  implies  th*  need  tor 
content  and  context  dependent  access  control  in  such 
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an  environment*  Thus,  there  la  an  Increased  need  for 
more  dynamic  protection  checking  with  later  binding 
times* 

5)  The  need  for  data  Independence  In  DBMS  requires  that 
definitions  of  the  data  objects  and  their  protection 
specifications  be  logical  entitles*  far  removed  from 
the  physically  oriented  objects  used  by  the  OS*  This 
is  required  also  to  reflect  the  semantics  of  the 
data* 

6)  A  richer  variety  of  access  types  is  needed  In  DBMS's* 
such  as  statistical  access*  administrative  access 
[FEBNE7Sa]*  etc*  Again*  OS's  usually  deal  with  phy¬ 
sical  access  types  such  as  read*  write*  and  execute* 

7)  In  an  OS*  data  units  correspond  to  real  resources. 

In  a  DBMS  there  may  exist  data  aggregates  (e*g*« 
views)  that  do  not  correspond  to  any  physical  entity 
but  are  dynamically  built  according  to  an  application 
request  (ASTBM76*  SUMMK77  ]. 

8)  In  a  DBMS  each  user  may  have  a  different  conceptual 
view  of  the  data  objects  and  their  relationships 
(e*g**  subschema*  submodels)* 

9)  Oner  interfaces  In  DBMS  are  usually  more  constrained 
(e*g*«  use  of  special  query  languages*  special  proce¬ 
dural  languages*  special  access  protocols*  "parame¬ 
tric"  access)* 

10)  The  lifetime  over  which  the  deta  is  used  is  normally 
longer  in  a  DBMS*  and  the  number  of  associated 
applications  is  usually  larger* 

ill  Objects  are  often  fposslbly  null)  sets  of  data  enti¬ 
tles*  defined  implicitly  by  predicates  as  character¬ 
istic  functions*  causing  them  to  oveiap  arbitrarily* 
The  tidy  definition  of  objects  as  disjoint  files 
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of  higher  level  checking*  too.  Convent  I  one  1 1 y*  DBMS  run  as 
large  applications  "on  top  of"  the  OS.  In  the  MULTISAFE 
project  (described  In  section  4.4.2)  It  has  been,  proposed 
that  all  external  storage  access  operations*  both  for  OS 
file  handling  and  for  DBMS  operations*  be  executed  and  cont¬ 
rolled  In  one  place — a  sort  of  Data  Base  Access  Method.  The 
OS  thes  operates  "on  top  of"  tbj  DBMS*  Instead,  of  vice 
versa.  The  checking  at  the  various  levels  can  than,  be  Inte¬ 
grated  and  coordinated. 


3.  NON— ARCMJ  TECT0RAL  APPROACHES  TO  DATABASE  PROTECTION 


This  section  uses  sons  selected  models  and  sjrstens  to 
Illustrate  the  state— of— the— art  of  non— architectural 
approaches  to  database  protection*  It  is  not  Intended  to  be 
a  complete  review  of  all  existing  database  protection  work. 

3.1  Models 

This  section  briefly  reviews  a  few  models  of  database 
protection.  Each  of  these  models  has*  since  Its  development 
as  a  descriptive  model*  evolved  as  the  "backbone"  of  a  cor¬ 
responding  architectural  approach  to  database  protection. 
The  models  are  discussed  here.  Ths  respective  system  archi¬ 
tectures  are  discussed  is  section  4. 


3.1.1  Hsito's  Attribute— Based  Model 
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their  directories  rnrouptoa  many  of  the  more  coaaonly  used 
file  structures  (e.g. ,  Inverted  riles.  Indexed  sequential, 
end  multilist)  as  special  cases*  A  record  In  a  file  is  a 
set  of  at trlbut e— value  pairs*  Selected  attribute— value 
pairs,  not  called  keywords,  are  used  In  an  Index  to  speed 
retrieval*  Records  having  keywords  In  conon  are  linked 
together  by  pointers  ?nto  lists  within  the  database*  Typi¬ 
cally,  a  record  is  a  node  in  several  lists  at  ons  time; 
1 • a* ,  each  record  can  be  an  Intersection  point  of  several 
linked  lists.  The  directory  for  a  file  contains  the  Infor¬ 
mation  necessary  for  rapid  processing  of  these  lists*  For 
example,  for  each  keyword,  the  directory  has  the  number  of 
lists  corresponding  to  the  keyword,  the  length  of  each  list, 
and  pointers  to  the  beginning  of  each  list*  Queries  are 


expressed  as  logical  (AND  and  OR)  combinations  of  keywords* 
Algorithms  have  been  developed  to  decode  the  directory 
entries  for  given  keywords  and  to  process  the,  possibly 
many,  corresponding  lists  of  records  in  parallel.  The 
algorithm  minimizes  the  total  number  of  records  inspected 
while  retrieving  the  records  which  correctly  answer  the 
query* 


Numerous  researchers  have  since  elaborated  on  the 
attribute-based  model  (often  called  the  "He lao— Horary" 
model),  including  work  reported  in  [YAOSB76,  1ELDJ76 ]•  The 
model  has  also  served  as  the  basis  for  implementation  of  the 
Highly  Secure  Database  Management  System  (HSDMS)  [HSIAD76a, 
HSIAD76b)  at  Ohio  State  Onlverslty*  HSDMS  has  been  demons¬ 
trated  to  be  viable  in  a  military  environment  using  a  Navy 
ocean  surveillance  application  database  (MANOF77).  An 
architectural  approach,  the  Data  Base  Computer  (DBC),  has 
since  been  based  on  the  sane  model  and  it  will  be  discussed 
in  section  4* 
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3*1.2  McCauley'*  Security  Atone 

Additional  concept*  are  Introduced  In  (MCCAilS)  which 
enhance  the  security  aspect*  of  the  at  tribute-bar  »d  nodal. 
Specific  atrlbute*  of  a  file  can  be  selected  a*  "security 
attributes"  and  used  to  group  records  for  security  purposes. 
A  security  attribute  and  Its  value  are  a  "security  keyword." 
Each  record  then  contains  a  set  of  zero  or  wore  security 
keywords  (security  attribute— value  pairs).  This  sot  is  a 
"security  atom"  and  all  records  having  the  sane  security 
aten  are  grouped  together  logically  by  "belonging  to"  that 
atea.  Security  atoms  are  disjoint  and  they  can  be  protected 
individually*  as  objects.  Th*  security  keywords  of  each 
access  request  themselves  form  security  atom  Is)*  and  they 
are  checked  against  a  list  of  protected  security  atoms  for 
an  access  decision.  This  mechanism*  along  with  others*  is 
used  In  HSDMS  and  the  DBC. 

3.1.3  Fernandez*  Model  of  Authorizat Ion 

Fernandez*  Summers*  and  Coleman  ( FEBNB7Sa )  have  devel¬ 
oped  a  fermal  model  of  authorization  which  can  Impose  access 
rules  *n  shared  databases  accessed  through  high  level  lan¬ 
guages  (e.g.*  PL/I).  Programming  language  extensions  allow 
for  database  Interaction  and  for  users  to  define  and  use 
views  af  the  data.  The  user's  intentions*  with  respect  to 
the  database  application*  ar*  mad*  explicit.  Enforcement 
can  ".eke  advantage  of  more  than  one  binding  time*  but  is 
accerapl lshed  primarily  at  compile  time. 

In  (PEBNE75b)  the  model  is  extended  by  s  data  structur¬ 
ing  scheme  to  facilitate  authorization  by  providing  flexible 
ways  to  define  access  rules.  As  these  access  rules  are 
entered*  their  effects  propagate  through  the  system*  and  the 
rules  ar*  then  discarded  (to  avoid  possible  internal  incon¬ 
sistency  with  later  rules).  Some  architectural  extensions 
to  this  approach  are  discussed  in  section  4. 
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3. I .4  Hartson's  Semantic  Modal  of  Database  Protection 

A  node I  of  protection  itaenttce  divides  protection  into 
authorization  and  enforcement  processes*  A  sodsl  Is  devel¬ 
oped  In  (HARTH76a)  as  a  semantic  bass  for  constructs  in  pro¬ 
tection  languages  used  by  authorlzera  to  express  protsctlon 
policies*  The  model  Is  based  on  sets  of  users*  resources* 
and  data  operations*  Predicates*  called  access  conditions* 
•lion  access  decisions  to  have  a  wide  range  of  dependency  on 
system  state*  Access  conditions  are  combined  and  evaluated 
by  the  enforcement  process  to  produce  the  access  decisions* 
Additional  protection  features  are  Introduced  In  (HARTB76b)* 
Access  history  keeping  allows  dependency  on  the  occurrence 
of  previous  data  operations*  Auxiliary  program  invocation 
provides  for  additional  procedural  protsctlon  measures  such 
as  auditing*  alarm  and  recovery*  and  threat  surveillance* 
The  tradeoff  between  precision  and  performance  Is  studied  in 
[HARTH771*  Here*  the  questions  of  enforcement  and  dynamics 
and  timing  are  addressed  in  the  context  of  the  semantic 
model  and  the  concept  of  access  decision  binding  tins  is 
introduced* 


3*2  Some  Experimental  Sy 


This  section  uses  a  few  existing  experimental  secure 
database  systems  to  illustrate  the  state— of— the— art  for  sys¬ 
tems  not  based  on  an  architectural  approach*  It  is  not  a 
complete  review  of  all  experimental  systems*  The  discussion 
emphasizes  two  recent  relational  database  systems:  INGRES 
(representing  academic  research)  and  System  B  (representing 
industrial  research)* 


3.2.1  ADEPT— 50 


Although  A  DEPT- SO  (WEISC691  la  nolthor  state-of-the-art 
nor  •  database  syitta,  It  aarna  a  brief  aention  herb  because 
It  la  one  of  the  firat  Military  oriented  atteapta  at  secura 
OS  flla  handling.  ADEPT— SO  provides  security  for  objects 
such  as  uaerSf  terminals*  Jobs*  sad  flies  is  a  tine  sharing 
environment.  In  a  set  theoretic  approach*  ADEPT— SO  features 
the  concept  of  a  "Job  umbrella*"  a  derived  elearaWee  of  a 
user/ termlnal/f 1 la  combination.  The  Job  umbrella's  "high 
eater  mark"  Is  ussd  to  automatically  classify  nee  flies 
created  by  a  Job. 

3.2.2  ASAP 

ASAP  ( CON WE 72]  is  an  example  of  an  early  information 
system  eith  security  mechanisms.  Data  Independent  checking 
Is  done  ehen  high  level  queries  are  compiled.  Field  level 
protection  Is  accomplished  by  assigning  each  usar  a  list  of 
security  classes  (based  on  attributes*  or  field  names) 
he/she  can  access.  Data  dependant  dhecking  in  dons  at  exe¬ 
cution  time  by  Boolean  expressions.  ASAP  in  now  available 
commercially. 

3.2.3  INGRB8 

INGRES  (Interactive  Graphics  and  Retrieval  System)  is  a 
relational  database  system  developed  and  Implemented  by  Sto— 
nebraker  and  others  at  the  University  of  California*  Berke¬ 
ley  [ STONN76a ].  The  approach  to  protection  taken  In  INGRES 
(STONM74)  has  attracted  a  lot  of  interest.  Queries*  in  a 
higb  level  query  language  language*  are  modified  (using 
information  about  what  kinds  of  queries  a  user  in  authorized 
to  ask)  as  they  enter  the  system.  Modiflcetlon  in  dons  In  a 
way  so  that  the  modified  version  of  the  query  Is  a  legal 
request.  In  other  words  the  modified  query  asks  for  only 
the  authorized  subset  of  what  the  original  query  requested. 
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Query  Modification  is  dona  before  retrieval  processing 
begins*  Retrieval  *ay  then  proceed*  using  the  Modified 
query*  without  further  access  checking*  This  high  level 
approach  to  protection  offers  easy  inplsMentation  and  saall 
execution  tiee  overhead* 

In  order  to  describe  the  say  in  which  query  Modifica¬ 
tion  is  accomplished*  the  concept  of  relational  databases  is 
sketched*  The  relational  nodel  of  data  probably  has  the 

distinction  of  being  the  Most  cospllcated  Model*  and - a t  the 

sane  tine — the  siaplest  nodel  of  data*  On  the  one  hand  the 
nodel  Is  associated  with  predicate  calculus*  nests  and 
Joins*  functional  dependency*  noraal  forns*  and  so  forth* 
On  the  other  hand  a  great  deal  of  understanding  can  be  had 
without  going  beyond  the  plain  fact  that  data  is  kept  in  a 
flat*  unstructured  table  (the  Most  natural  forn  lnaglnable) 
without  pointers*  hierarchies*  or  even  any  conputer  related 
notions*  The  protection  of  INGRES  can  be  explained  without 
departing  far  fron  this  sinple  view*  The  following  exanpleo 
I Most  exaMples  in  this  section  are  adapted  fron  ISTONM741) 
will  be  used  to  deaonstrat*  INGRES  query  Modification*  Con¬ 
sider  this  relation  ( table  of  data)*  naned  EMPLOYEE: 


HAMB 

PEPT 

PAM  El 

MANAGER 

Snith 

toy 

10*000 

Jones 

Jones 

toy 

15*000 

Johnson 

ideas 

candy 

12,000 

Baker 

Evans 

candy 

14,000 

Todd 

Baker 

adni  n 

20,000 

Harding 

Harding 

adnln 

40,000 

none 

This  table  slnply  lists  values  for  four  attributes  of 
enployees  of  a  certain  conpany*  The  query  language  used  to 
retrelve  (and  update)  data  in  INGRES  is  called  QOBL  (QOEry 
Language)  and  is  typical  of  a  clans  of  such  languages  which 
retrieve  by  data  naae  and  content  and  do  not  require  know¬ 
ledge  of  data  structure  or  retrieval  algorithas* 
(  SEQUEL—  Structured  English  QUBry  Language  [ ASTRM76  1— is 
another  language  of  this  type*)  (hierles  in  these  languages 
typically  have  parts  that  state  in  sinple  terns: 
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a)  th«  nan*  «f  uRtr  work  tru  In  which  the  retrieved 
date  la  to  be  returned 

b)  the  name  of  the  attlbutea  to  retrieve 

c)  the  neae  of  the  table  to  retrieve  free 

d)  a  condition  for  selecting  rowe  to  be  retrieved 

The  following  query  Is  adapted  to  Illustrate  the  uee  of  a 
language  like  QUEL  or  SEQUEL  for  retrieval  frea  a  single 
table: 

INTO  V 

RETRIEVE  SALARY 
FROM  EBP 

WHERE  NAME  »  • JONES 

The  Individual  parts  are  explained  as  follows: 

INTO  f~the  nase  of  the  user  work  area  In  which  to  put  the 
retrieved  data* 

RETRIEVE  SALARY — for  whatever  rows  are  retrieved,  it  Is  the 
SALARY  attribute  (colusn)  which  Is  of  Interest  in  this 
query  (other  attributes  will  not  be  given  to  the  uteri • 
FROM  EMP — the  nase  of  the  table  f row  which  to  retrieve* 

WHERE  NAME  *  • JONES' — the  condition  (attribute  and  value)  to 
be  used  for  selecting  rows  to  be  retrieved* 

Pros  the  sasple  database,  this  query  would  select  one  row, 
nasely  the  second  row  (an  this  is  the  only  row  having  a 
value  of  *  JONHS*  for  the  NAME  attribute)  ahd  return  the 
SALARY  value  of  that  row,  nasely  15,000,  to  the  requesting 
user's  work  area  (buffer)  nased  "W . *  The  attributes  to  be 
retrieved  (SALARY  above)  are  called  "target"  attributes* 

An  access  control  restriction  for  a  user  cen  Itself  be 
specified  in  the  fora  of  a  query*  For  exasple,  suppose  that 
Snlth  can  see  only  lnforsation  about  hiaself  (i*e*,  rows 
where  NAME  *  'SMITH* )•  A  query— like  stateaent  of  this  res¬ 
triction  Is! 

INTO  W 

PERMIT  NAMB,  DEPT,  SALARY,  MANAGBR 
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FROM  EMP 

WHERE  NAME  =  • SMITH* 

If  Smith  lnqulr««  about  tha  salary  of  Jones  with! 

INTO  W 

BETB1EVE  SALABT 
FROM  EMP 

WHERE  NAME  »  • JONES* 

tha  query  la  modified  with  tha  restriction  by  forming  a  log¬ 
ical  AND  of  tha  conditions! 

INTO  W 

RETRIEVE  SALARY 
FROM  EMP 

WHERE  NAME  *  *  JONES*  AND  NAME  *  •SMITH* 

Since  each  row  can  have  only  one  value  for  tha  NAME  attri¬ 
bute  and  since  this  modified  query  asks  to  select  all  rows 
with  both  values  under  the  NAME  attribute,  no  records  are 
retrieved  and  the  illegal  request  Is  successfully  denied. 
In  general*  the  modified  selection  condition  becomes  the 
original  query  condition  ANDed  with  a  quantity  which  is  the 
logical  OR  of  all  appl icable  access  control  specifications. 
Given  this  additional  control  specification*  allowing  Smith 
to  see  information  about  people  who  are  in  the  candy  depart¬ 
ment: 


INTO  W 

PERMIT  NAME,  DEPT*  SALARY*  MANAGER 
FROM  EMP 

WHERE  DEPT  *  'CANDY* 

Query  selection  predicates  will  then  be  ANDed  with! 

NAME  = ' SMITH*  OR  DEPT  »*CANDY* 

The  single  relation  (only  the  EMPLOYEB  information} 
bides  some  complexity*  but  serves  well  to  illustrate  the 
principle.  Cases  involving  nore  than  one  relation  and  quer¬ 
ies  involving  aggregates  (e. g.*  the  average  of  all  salaries 
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in  a  certain  department)  are  detailed  in  ( STONM74  )•  Certain 
anenoliea  are  aesoclated  with  querlei  Involving  pggreg atee« 
and  eoae  uaere  might  consider  it  a  drawback  to  get  anavere 
to  queries  which  are  different  from  those  cotergd  Into  the 
system  {especially  if  they  don't  know  what  qqariea  the 
answers  do  match)* 

As  INGRES  Is  implemented  on  the  CNil  operating  system* 
it  is  afforded  physical  file  protection  by  UNIX  and  can  take 
advantage  of  its  tree  structured  file  and  directory  organi¬ 
zation*  Extensions  have  also  been  designed  for  implementing 
INGRES  as  a  distributed  database  system  [STONM76bl  in  a  net¬ 
work  of  UNIX  based  systems*  A  development  more  important  to 
this  report  is  the  adaptation  by  Mitre  of  INGRES  to  run  with 
a  secure  kernel lzed  UNIX  and  to  Incorporate  multilevel  DoD 
security  policies  and  controls  {WAGNB77)* 

3*2*4  System  B 

System  By  developed  and  implemented  at  IBM's  San  Jose 
Research  Laboratory*  is  perhaps  the  most  complete  experimen¬ 
tal  relational  database  system  in  the  United  Staten 
( ASTRM76 ] •  In  addition  to  the  access  control  mechanisms* 
there  are  also  provisions  for  semantic  integrity  assertions* 
logging  and  recovery*  concurrency  interlocking  at  many  lev¬ 
els  of  granularl ty«  and  "triggering"  of  transactions  by 
database  events*  In  System  R  a  table  is  an  existing  rela¬ 
tion  as  it  resides  in  the  database*  A  table  can  also  be  a 
"view*"  or  logical  variation  derived  from  an  existing  table* 
Views  can  be  tailored  to  the  needs  and  applications  of  indi¬ 
vidual  users*  Authorized  users  creating  new  tables  {either 
relations  or  views)  can  automatically  have  access  rights  to 
access  them  and  to  share  these  rights  with  others*  The 
enforcement  mechanism  simply  checks  to  soe  if  a  requesting 
user  has  been  granted  {by  someone)  the  right  to  perform  the 
requested  operation  on  a  given  tables  The  access  privilege 
information  is  an  access  list  [LAMPB71]*  also  stored  as  a 
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relation*  By  this  Information  the  user  Is  kept  within 
his/her  view*  Attempts  to  writs  outside  this  view  are  pro¬ 
tection  violations  and  attempts  to  read  from  outside  it 
yield  the  null  response*  This  enforcement  checkins  is  done 
at  access  time  (not  compile  time)  and  is  done  once  per 
"transaction***  A  transaction*  which  can  encompass  several 
related  database  commands*  is  the  unit  of  protection  and 
lntesr ity  locking  in  System  B* 

Creators  of  tables  can  not  only  propagate  access 
rights*  but  they  can  propagate  the  right  to  grant  further 
access  rights*  Therefore*  more  than  one  authorizer  can 
grant  access  privileges  to  the  same  object*  This  serves  a 
need  for  decentralized  authorization*  but  complicates  the 
revocation  process*  Now*  to  achieve  a  desired  state  of 
authorization*  an  entire  chain  of  grants  might  have  to  be 
revoked*  In  IGBIFP76]  one  particular  policy  (built  into  the 
mechanisms)  is  described  which  attempts  to  return  as  closely 
as  possible  to  the  authorization  state  which  would  exist  if 
the  revoked  authorization  had  never  been  granted*  (It  is 
claimed  that  the  whole, system  returns  to  it  original  state* 
but  most  likely  it  was  intended  to  refer  to  Just  the  state 
of  the  authorization  information*  Obviously*  previous  data¬ 
base  accesses  made  under  the  privilege  being  revoked  are 
irreversible*)  In  achieving  this  state  all  grants  propagat¬ 
ing  from  the  revoked  grant  are  also  revoked*  except  those 
"supported"  by  a  previous  grant  from  another  (not  being 
revoked)  source*  Time  stamps  are  used  to  establish  relative 
timing  of  grants  and  revocations*  A  recursive  algorithm* 
which  traverses  the  graph  of  grant  sequences*  is  given  in 
(GBIPP76)  to  accomplish  this  revocation* 

INCBBS  and  System  B  are  further  described  and  compared 
in  (MCLEJD771*  It  is  said  that  the  revocation  mechanism  des¬ 
cribed  above  is  not  Implemented  in  System  B* 
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4.  architectural  approaches 


4.1  introduction  and  Motivation 


Tha  functional  requirements  of  aactlon  If  and  underly¬ 
ing  security  mechanisms  needed  to  support  these  requirements 
according  to  the  principles  of  section  2.  impose  the  need 
for  these  very  general  characteristics  in  a  system  design: 
modularity,  simplicity,  lsolatahi lity.  and  flexibility.  It 
has  been  observed  [MANOF77]  that  thus  far  the  solutions  to 
data  security  problems  have  largely  been  ad  hoc  and  brute 
force.  A  view  that  can  stand  back  and  consider  the  entire 
system  architecture!  rather  than  concentrating  on  tuning  up 
individual  mechanisms.  offers  hope  for  more  elegant  solu¬ 
tions  in  the  future.  Perhaps  the  single  most  Important  con¬ 
clusion  of  this  report  is.  not  to  suggest  a  solution  or  a 
particular  system.  but  to  recommend  a  direction  and  an 
approach.  The  hulk  of  the  evidence  and  information  that 
vent  into  the  making  of  this  report  points  toward  system 
architecture  approaches  an  the  most  effective  way  to  satisfy 
the  increasingly  complex  and  often  competing  requirements. 
In  fact.  it  appears  to  he  the  only  approach  in  which  the 
design  of  such  large  systems  can  be  understood  and  believed 
to  be  secure. 

In  (MARYP78]  the  separation  of  DBMS  functions  from 
applications  programs  is  argued  because  then  "software  that 
spies  on  the  database  cannot  he  constructed."  Claybrook 
l CLAY B7 8]  shrws  that  the  distribution  of  functions  in  a  DBMS 
results  in: 

a)  specialized  modules 

b)  smaller  and  simpler  modul es 

c)  small  operating  system,  kernels,  and  other  subsystems 

d)  more  easilv  verified  security  kernels 


Modular  system  archltectur*  approaches*  such  as  tha 
functional  specialization  in  Ohio  State's  DBC  and  the  func¬ 


tional  distribution  of  Virginia  Tech's  MULTISAFB*  offer - In 

addition  to  the  advantage*  listed  above: 

a)  isolation  of  protection  functions  (In  accord  with  the 
softeare  concept  of  a  security  kernel) 

b)  Integration  of  many  security  related  functions 

c)  elimination  of  "back  doors"  (all  access  paths  to  the 
database  are  Identified) 

d)  a  well  structured  aystea 

The  last  point,  that  of  structuring  the  system  is 
important*  Good  structuring  provides  for  a  clean  design, 
from  the  hardware  on  up*  As  Jones  and  Llpton  (JONEA7S)  have 
put  it:  "in  order  to  be  credible  the  basic  framework  must 

be  simple  and  clear*  No  one  will  believe  an  unstructured 
system  is  secure*"  It  is  now  widely  accepted  that*  although 
a  small  amount  of  clever  assembly  language  code  for  a  func¬ 
tion  can  be  very  efficient (  It  Is  not  as  reliable  and  easy 
to  understand  as  if  it  were  structured  and  in  a  higher  level 
language*  So  It  Is  In  systems*  especially  systems  In  which 
security  is  important'  and  systems  that  will  be  maintained 
over  periods  of  years*  As  with  structured  programs*  struc¬ 
tured  systems  may  suffer  small  performance  penalties  com¬ 
pared  to  "clever"  non— structured  systems*  For  example*  res¬ 
ponse  time  might  be  higher  due  to  Increased  communication 
paths  to  isolated  protection  functions*  The  added  overhead 
must  be  accepted  as  part  of  the  cost  of  doing  business  prop¬ 
erly* 


4*2  Architectural  Approaches  to  Database  Management 


In  the  late  1960's  and  early  1970's  it  was  recognized 
that*  since  data  on  secondary  storage  devices  must  be  moved 
Into  the  CPO  for  processing*  it  would  be  beneficial  for 
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appl lea t 1 on«  such  aa  DBMS  to  nova  Home.  processing .capabl 11- 
tlu  out  into  aacondary  devices*  The  presence  of  functions 
for  aearchlngt  coaparingf  and  coablnlng  data  aade  the  secon¬ 
dary  storage  systea  appear  to  the  CPU  as  an  associative 
retrieval  systea*  These  associative  approaches  to  database 
searching  have  been  shown  to  have  performance  advantages 
over  conventional  file  and  index  organizations  [DEF1C71* 
DEFXC73,  BERBP74)* 

Researchers  at  the  University  of  Florida  [COPEG73* 
SUSTW73J  developed  a  stand-alone*  associative*  cellular  sys¬ 
tem  called  CASSM*  which  is  constructed  by  attaching  logic 
units  te  a  head— per— t rack*  segmented  rotating!  storage  dev¬ 
ise*  CASSM  was  designed  te  support  general  database  struc¬ 
tures  suoh  am  hierarchies*  Data  manipulation  is  accom¬ 
plished  within  the  secondary  memory  without  the  need  for 
control  by  the  CPU*  A  relational  associative  processor 
(Kill  was  designed  at  the  University  of  Toronto  ( OZKAE7S* 
OZKAB77  J  *  and  it  also  is  a  stand-alone  rotating  head-par— 
track  scheme  for  supporting  relational  databases*  BAP  fol¬ 
lowed  the  idea  of  cellular  architecture  as  found  in  CASSM* 
but  with  more  sophl of icated  logic  for  database  accessing 
that  improved  processing  time*  BAP  can  handle  very  large 
databases  I up  to  100  megabits  and  larger)*  Later*  at  the 
University  of  Utah  1LINCS761  a  rotating  associative  storage 
device* .called  BABES*  was  proposed  for  relational  databases* 
In  BABES  search  logic  is  attached  to  the  fixed  heads*  BABBS 
stores  data  across  adjacent  tracks*  whereas  CASSM  and  RAP 
store  data  along  adjacent  tracks* 

A  system  called  infoplex  IMADNS7S)  is  being  designed  at 
MIT  to  access  databases  through  a  hierarchical  complex  of 
low— cost  microprocessors*  This  system  achieves  a  high 
degree  of  parallelism  and  pipelining  facilitated  by  the 
liberal  use  of  queueing  between  levels  of  processors  in  the 
hierarchy* 
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One  of  the  earliest  associativa  DBMS  >ai  tha  Informa— 
tlon  System  For  Associative  Memories  ( I FAM ) — developed  for, 
and  partly  by,  the  Rome  Air  Development  Center  ( RADC )  and 
Implemented  In  1971  on  the  Goodyear  associative  memory* 
Associative  memories,  because  of  economic  considerations, 
must  be  small  (for  example,  the  RADC  STARAN  uses  four  arrays 
of  256  by  256  bytes)*  The  problem,  therefore,  with  using 
associative  memories  for  database  operations  has  been  the 
time  required  for  loading  the  associative  memory  from  secon¬ 
dary  storage.  Hovever,  important  recent  results  from  RADC 
(FARND761  have  shown  the  feasibility  of  a  gigabit  storage 
device  which  eliminates  the  delays  In  loading  the  associa¬ 
tive  memory,  by  transferring  whole  blocks  at  a  time*  Based 
on  this  new  memory  technology,  RELACS,  an  associative  compu¬ 
ter  architecture  for  supporting  a  relational  data  model.  Is 
currently  being  designed  at  Syracuse  University  (OLIVE79). 

In  1974  Canaday  et  al*  (CANAR74]  reported  a  somewhat 
different  approach.  Instead  of  designing  special  purpose 
hardware  to  build  into  the  secondary  storage  devices,  they 
employed  a  general  purpose  minicomputer  connected  with  stan¬ 
dard  disk  drives  as  a  "back-end  computer”  (BEC)*  As  did  the 
associative  devices,  the  back-end  computer  accepted  DBMS 
commands  from  the  CPU  and  returned  results  without  requiring 
interim  processing  by  the  CPO*  The  following  year  Kansas 
State  University,  in  an  effort  sponsored  by  AIRM1CS 
(AIRMI78),  began  to  explore  distributed  processing  and  the 
applicability  of  DBMS  to  Army  problems*  KSU  researchers 
Investigated  the  use  of  BEC* s  and  the  application  of  BEC* s 
to  production  quality  DBMS  { MARTF76a,  MARTF76b]*  Under  the 
Joint  support  of  the  O.  S*  Army  Computer  Systems  Command 
(USACSC),  the  Naval  Ship  Research  and  Development  Center 
(NSRDC),  the  Naval  Material  Command  Support  Activity 
(NMCSA) ,  and  another  DoD  agency,  Culllnane  Corporation 
developed  a  prototype  version  of  the  I DWS  database  system  on 
a  BEC*  The  work  at  KSU  provided  the  basic  process  protocol 
methodology  that  was  used  to  develop  the  inter-computer  mes¬ 
sage  system  In  the  Culllnane  prototype* 
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The  architectural  approaches  described  in  this  section 
are  largely  oriented  toward  efficient  storage  and  retrieval 
in  DBMS*  Little  or  no  emphasis  has  been  given  tp  security 
In  these  systems* 


4*3  Architectural  Approaches  to  Secure  DBMS 


After  the  separation  of  DBMS  functions  from  the  CPU,  as 
described  In  the  preceedlng  section*  it  was  realized 
that — Is  addition  to  advantages  In  storage  and 
retrieval— there  could  be  some  advantages  with  respect  to 
security*  The  kind  of  Isolation  and  aodularlzatlon  provided 
by  a  BEC  vers  ideal  for  the  elimination  of  "back  doors"  and 
other  threats  to  security  found  in  more  traditional  DBMS* 
The  BEC  concept  Is  also  highly  compatible  with  the  notion  of 
a  security  kernel*  The  BEC*  in  fact*  can  contain  a  data 
security  kernel*  In  Fernandez*  system  architecture  (dis¬ 
cussed  later  In  this  section)  and  MULTISAFE  (section  4.4*2) 
the  protection  functions  are  even  separated  from  the  DBMS* 
as  well  as  the  applications  and  user  programs* 

Blsbey  and  Popek  (BISBB74)  "encapsulated"  the  OS  and 
security  software  on  a  minicomputer  away  from  the  user  and 
application  software*  It  was  then  easier  to  certify  the 
system  from  malicious  attacks  through  user  or  application 
software*  Downs  and  Popek  { DOVND77 ]  then  extended  this  to 
the  pro'ilesi  of  secure  database  management*  Data  security 
modules  reside  In  the  nucleus  of  the  DBMS  as  a  data  security 
kernel*  The  data  management  module*  which  maps  logical  data 
structures  Into  physical  data  structures*  is  supported  by  a 
separate  "data  management  kernel*"  All  physical  update  and 
retrieval  operations  are  performed  by  the  data  management 
kernel*  For  aid  in  updating*  a  second  kernel*  called  the 
"kernel  Input  module*"  is  used  for  obtaining  the  update  data 
from  the  user's  update  request*  because  the  data  management 


module  does  not  handle  actual  data.  The  Input  data  are 
matched  with  their  corresponding  physical  structures  sup¬ 
plied  from  the  data  management  module.  After  security 
checking*  the  data  management  kernel  Issues  a  physical  1/0 
request  that  performs  the  actual  update.  For  data 
retrieval*  the  kernel  Input  module  1s  not  Involved.  The 
data  management  kernel  validates  the  retrieval  request  from 
the  data  management  module  prior  to  issuing  a  physical  data¬ 
base  access. 

In  an  effort  to  improve  security  and  reduce  the  sensi¬ 
tivity  of  compt le— t lme  checking  to  changes  In  the  database 
and/or  the  authorization  rules*  Lang*  Fernandez*  and  Summers 
(LANGT761  proposed  a  division  of  applications  software 
(object  programs)  into  three  parltlonsS 

1)  the  non— database  application  object  nodule  (A— pro¬ 
gram) 

2)  the  data  interaction  object  module  (D— program) 

3)  the  data  control  object  module  (C— program) 

As  the  A— program  executes*  a  call  Is  made  to  the  1>— pro¬ 
gram  whenever  there  is'  a  need  for  database  manipulation. 
The  D— program  then  calls  the  C— program  for  all  protection 
checks  before  responding  to  the  A— program.  Neither  the 
A— program  nor  the  C— program  can  access  the  database  and  all 
security  related  functions  are  now  concentrated  in  one 
place*  the  C— program.  Now  changes  in  data  structures  or 
access  rules  do  not  require  recompilation  of  the  entire 
applications  program.  Instead*  only  the  C— program  or  parts 
of  the  D-program  must  be  recompiled.  In  (FEBNE78)  a  sot  of 
architectural  extensions  to  an  IBM/370  type  sachint  are  pro¬ 
posed  to  accomodate  this  new  system  architecture. 

Following  the  development  by  Sbaefer  and  Hlnke  at  SDC 
[HINKT75]  of  a  secure  relational  data  management  system  for 
MULTICS*  Klrkby  and  Grohn  at  I.  P.  Sharpe  (KIBKG77a)  des¬ 
cribe  a  reference  monitor  technique  extending  (GBOHM761  the 
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Bell  and  LnPadula  model  of  DoD  security  policy*  Model 

enhancement  a  Include  concepts  from  flow  analysis  (DENND761* 
The  DMS  kernel  la  specified  with  Pa  mas- type  specification 
techniques  [Kl»lC71b]  and  verified  to  be  secure  (KtKltG77e)* 
Protection  granularity*  however*  appears  to  be  only  at  the 
relation  (file)  level*  Their  work  has  taken  a  "bracketing* 
approach  to  reference  monitor Ins*  in  which  a  front-end  pro¬ 
cessor  (software)  Monitors  communication  between  user  termi¬ 
nals  and  the  CPO  and  a  back-end  processor  (also  software) 
between  the  CPU  and  peripheral  memory*  The  front-end  and 
back-end  processors  are  added-on  to  an  of f— the— shelf  OS* 
•enerality  ef  the  approach  has  been  demonstrated  to  the 
extent  that  the  concept  applies  to  both  MVS/370  and  PDP-11 
USX.  This  work  is  not  yet  implemented* 

The  addition  of  a  Data  Base  Machine  (DBM)  to  WWMCCS  has 
been  addressed  in  a  study  by  Systems  Development  Corporation 
(SDC)  done  for  the  Defense  Communications  Agency  (DCA) 
[CADYC78I*  The  basic  objective  of  the  SDC  study  Is  to  pro¬ 
vide  Improved  security  of  shared  WWMCCS  databases  without 
any  new  performance  penalties*  The  DBM  approach  is  used 

because  of  the  advantages  which  have  been  expressed  In  this 
present  report*  Some  of  the  security  features  proposed 
appear  to  be  "add  on"  rather  than  being  integrated  Into  the 
heart  ef  the  WWMCCS  design*  Bov  well  they  can  eventually  be 
Integrated  depends  largely  on  how  well  **HCCS  was  originally 
designed  In  terms  of  flexibility  for  change*  Claybrook.. 
(CLAYB78)  is  studying  for  DCA  sose  aspects  of  the  addition 
of  DBM*  s  to  SikCCS  and  tba  effects  that  such  architectural 
changes  might  have  on  security  policy* 

Cary  (CARYJ79)  and  Hoffsan  at  George  Washington  Univer¬ 
sity  are  working  on  a  secure  DBMS  which  Isolates  database 
functions  across  a  set  of  functionally  specified  hardware* 
This  approach  esphaslzes  single  or  multipoint  reel— time  sur¬ 
veillance  and  threat  monitoring*  This  approach  appears  to 
be  very  suitable  to  implement  the  functions  of  s  WWMCCS  ADP 
System  Security  Officer  (WASSO)  terminal* 
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Thera  is  on#  nev  probiea  Introduced  by  t he  various 
architectural  approaches  to  secure  DBMS*  The  Isolation  of 
DBMS  functions  Into  a  B EC  or  DBM  requires  careful  considera¬ 
tion  of  the  security  of  messages  between  the  database  pro¬ 
cessor  and  the  sain  CPU.  This  Is  a  different  issue  f roe 
that  of  network  coaeunica t 1 one  security  and  Is  discussed 
briefly  with  respect  to  MULTISAPE  In  section  4. 4*2* 

4*4  Some  Experimental  Systems 

Two  experimental  systems*  the  Ohio  State  University 
Data  Base  Computer  (DBC)  and  the  Virginia  Polytechnic  Insti¬ 
tute  and  State  University  MULTISAFE*  are  chosen  as  examples 
of  Integrated  system  architecture  approaches  to  secure  data¬ 
base  management*  Similar  work  might  possibly  be  underway 
presently  at  other  places  under  the  wraps  of  secrecy*  but 
these  were  the  only  systems  of  this  type  which  could  be  dis¬ 
covered  during  this  study*  The  work  at  Ohio  State*  directed 
by  Professor  David  Hsiao*  and  the  VP1  6  SV  work  employ  fun¬ 
damentally  different  approaches*  The  two  systems*  being  at 
different  levels  and  involving  different  structures*  are 
complementary  rather  than  competing*  The  DBC  is  much  more 
highly  developed  than  the  MULTI  SAFE  project  and  volumes  of 
details  (especially  in  terms  of  design  and  Implementation) 
are  available  from  0*S*U*  technical  reports*  Currently*  in 
fact*  an  experimental  software  version  of  the  DBC  is  imple¬ 
mented*  and  a  hardware  version  is  being  considered  for  pro¬ 
totype  implementation  by  a  commercial  computer  manufacturer* 
MULTISAFE  is  still  very  much  in  the  conceptual  stages*' 

4*4*1  The  Ohio  State  Data  Base  Computer  (DBC) 

The  Ohio  State  Database  Computer  (DBC)  (BANBJ78)  is  a 
functionally  specialized  architectural  approach  to  high  per¬ 
formance*  secure  data  management  based  on  near  term  future 


38 


technology*  Using  special  purpose  hardware,  it  extends  and 
combines  the  concepts  of  back-end  processors  and  associative 
processors*  The  history  of  the  DBC  begins  back  with  Hsiao's 
attribute— based  data  nodal  (section  3*1*1)  and  includes 
McCauley's  security  atone  (section  3*1*2)*  the  Highly  Secure 
Oats  Managenent  Systen  (HSDMS)  (  HSlAD76a,  HSIAD76b)«  and 
Baum's  f BA0M875 J  design  of  a  system  architecture*  The  moti¬ 
vation  for  specialized  hardware  is  the  fact  that  modules 
performing  DBMS  functions  need  diverse  performance  capabili¬ 
ties  for  a  balanced  high  level  through-put*  This  diversity 
cannot  be  obtained  if  all  the  functions  are  implemented  on 
the  same  underlying  hardware* 

o 

Operating  as  a  BEC  with  a  special  OS*  the  DBC  is  not 
constrained  to  be  used  with  any  particular  kind  of  general 
purpose  host  computer*  In  fact,  several  host  computers  can 
share  the  DBC ,  possibly  in  a  distributed  data  environment* 

A  key  design  concept  within  the  DBC  is  the  partitioned 
content  addressable  memory  (PCAM)*  Large  fully  associative 
memories  are  not  feasible  under  current  technology* 
Instead*  the  DBC  uses  ie  hierarchy  of  advanced  technology  to 
provide  numerous  smaller  associative  memories  at  varying 
levels  of  capacity  and  access  speed*  A  block  of  the  stored 
data  resides  in  a  partition  of  content  addressable  memory  at 
some  level  within  this  hierarchy* 

A  schematic  diagram  of  the  flow  of  information  and  con¬ 
trol  In  the  DBC  is  taken  from  [BAUMB76]  and  appears  here  as 
figure  1*  The  operation  of  the  system  is  divided  Into  two 
" loops* "  Common  to  both  loops  is  the  Data  Base  Command  and 
Control  Processor  (DBCCP)  which  serves  as  an  Interface  with 
the  host  computer*  controls  the  operation  of  both  loops* 
schedules  execution  of  all  database  commands*  and  does  part 
of  the  security  checking*  Bequests  from  the  Program  Execu¬ 
tion  System  (PES)  enter  the  DBCCP  and  are  processed  by  the 
upper  loop  ("structure  loop")  with  respect  to  structural 
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Information  (HSIAD76c).  The  keyword  transformation  unit 
( KXUI  converts  keywords  into  ths  Internal  forms  used  by  the 
rest  of  the  system*  The  structure  memory  (SM)  stores  and 
retrieves  the  lerge  amount  of  structural  information  about 
the  database*  PCAM* s  are  used  to  implement  the  SM*  A 
"look— aside"  buffer  maintains  high  SM  performance  during 
updates*  The  structure  memory  information  processor  ( SMI P) « 
which  also  uses  PCAM*s*  performs  set  operations  on  struc¬ 
tural  information  from  the  SM*  Then  the  index  translation 
unit  11X0)  decodes  and  returns  to  the  DBCCP  structural 
information  from  ths  SM1P*  Ths  four  units  operate  concur¬ 
rently  in  a  pipeline* 

The  lower  loop  I  the  data  loop)  is  then  used  for  data 
retrieval  (and  update)*  Ths  data  loop  contains  the  mass 
memory  (MM)*  where  the  database  In  stored  in  PCAM's*  and  the 
security  filter  processor  (SFP)*  which  does  sorting  and  any 
security  checkins  beyond  that  which  can  be  done  by  security 
atoms  (see  section  3*1*21*  In  the  MM  a  partition  of  a  PCAM 
is  a  cylinder  of  a  moving  bead  disk  memory*  (New  advances 
in  associative  memory  technology  would  allow  for  replacing 
any  present  PCAM  hardware  with  cheaper*  faster*  and  more 
reliable  devices— such  as  an  array  of  microprocessors  and 
their  semorles — without  affecting  any  of  the  DBC  design*) 
Track  information  processors  (TIP(s)  provide  associative 
access  to  each  cylinders*  and  all  tracks  of  a  cylinder  are 
processed  simultaneously*  The  MM  can  search  for  and  ret¬ 
rieve  records  that  satisfy  queries*  In  addition  to  the 
security  checking  based  on  security  atoms*  which  can  be  done 
at  directory  translation  time*  security  checking  can  be  done 
using  security  specifications  which  are  kept  by  the  PES  In 
the  form  of  user  capabilities*  These  security  specifica¬ 
tions  are  expressed  in  the  same  fora  as  are  queries*  allow¬ 
ing  the  full  power  of  the  query  language  io  specify  records 
to  be  protected*  The  SFP  checks  retrieved  data  (but  not  yet 
returned  to  the  user)  against  these  specifications* 


The  DBC  has  also  been  «ho»n  to  bo  out  tod  aa  a  baao  eye— 
toa  for  higher  levol  data  aodola  ouch  aa  tho  hierarchical 
t  HSI AD77 1«  tho  network  ( BANEJ77a ] t  and  tho  relational 
( BAN E J77b ) •  Results  of  a  elouiatlon  atudy  relating  roiponao 
tlaest  loading  conditional  and  through-put  la  available 
(HSIAD78a). 

4.4.2  MULTI SAFE 

A  MULTIprocessor  system  for  aupportlng  Secure  Authori¬ 
zation  with  Full  Enforcement  (MULTI  SAFE)  for  databaao  man¬ 
agement  la  now  being  developed  (TBUEB78)  by  Trueblood  and 
Hartaon  at  VP  I  6  SO.  The  goela  of  the  nee  ayatea  organiza¬ 
tion  are  loprovenenta  in  performance  and  security!  to  bo 
achieved  by  combining  the  concepts  of  aultiprocesslngi  pipe¬ 
lining!  and  parallellaa. 

The  nee  ayatea  configuration  la  baaed  on  functionally 
dividing  a  DBMS  Into  three  major  aodulee: 

1.  the  uaer  and  application  module  (UAM) 

2.  the  data  storage  and  retrieval  nodule  (SBM) 

3.  the  protection  and  aecurlty  module  (PSM) 

The  baalc  idee  la  to  implement  each  module  on  one  or  more 
processors  forming  the  aultiproceaaor  ayatem  called  MULTI- 
SAFE.  These  proceasora  can  be  aa  small  as  microprocessors* 
or  they  can  be  as  large  aa  aaxl processors  (full  sized  main 
frame  processors).  In  a  conventional  uniprocessor  environ¬ 
ment  these  three  modules  function  sequentially  In  an  Inter¬ 
leaved  fashion.  In  MULTISAFE  all  three  modules  function  in 

I 

a  concurrent  fashion.  That  la*  the  UAM  coordinates  and  ana¬ 
lyzes  user  requests  at  the  same  time  that  the  SBM  generates 
reaponsea  for  requests.  Simultaneously!  the  PSM  continu¬ 
ously  performs  security  checks  on  all  activities. 

The  basic  (or  minimal)  multiprocessor  architecture  for 
MULTI SAFE  is  composed  of  three  separate  processors  vhich  ere 
connected  to  three  separate  primary  random  access  memory 
blocks.  Thusi  each  functional  module  has  its  own  processor 
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and  primary  memory*  Tha  system  organization  folio**  tho 
mult  1 port- memory  organization  with  private  memorial 

( ENSLP77 J*  A  memory  li  made  "private"  by  connecting  only 
certain  proceeeore  to  it*  thereby  providing  phyelcal  eepa ra¬ 
tion  between  the  ueer* a  memory  and  the  PSM  and  SRM  memoriae* 
for  example.  Thle  eeparatlon  (or  Isolation)  can  slgnlfl— 
cantly  improve  security  becauee  it  in  physically  impoeelble 
for  a  ueer  to  acceea  the  PSM  or  tho  SRM  memoriae*  Syatem 
performance  Is  also  enhanced  by  the  concurrent  processing* 

With  this  new  MULTISAFB  approach  there  are  some 
expected  advantages  aa  well  as  disadvantages.  The  advan¬ 
tages  of  tha  architecture  are  ae  follows: 

1*  better  performance— concurrent  processing 

2*  Improved  security— more  powerful  mechanisms 

3*  Improved  verifiability— isolation  of  mechanisms 

4*  modularity — changeability  of  software 

Performance  penalties  are  avoided  by  overlapping  the 
processing  time  of  the  PSM  with  that  of  the  DAM  and  SKM* 
Greater  resolution  of  enforcement  can  therefore  be  had  with¬ 
out  substantially  degrading  the  performance  of  the  overall 
system*  Security  la  improved  because  a  separate  processor 
has  been  dedicated  for'  administering  the  protection  poli¬ 
cies*  The  processing  paths  through  the  system  are  cont¬ 
rolled  by  this  processor*  The  protection  processor  operates 
concurrently  with  other  processors  with  the  capability  of 
interrupting  their  processing  at  any  point  in  tine*  This 
capability  provides  for  more  flexibility  in  the  security 
mechanisms — particularly*  with  regard  to  the  tines  and 
places  where  access  decisions  can  be  made*  in  summary  the 
new  system  architecture* 

1*  reduces  the  possibility  of  "back  doors"  or 
sneak  p«ths*  by  isolating  tbs  protection 
nechanisns  and  by  forcing  all  accesses  of  data 
to  occur  through  a  single  path; 

2*  offers  safer  failure  modes*  by  showing  that 
failures  or  penetrations  of  hardware  or  soft¬ 
ware  outside  of  the  PSM  cannot  compromise 
security*  and 

•  features  a  relationship  between  the  operating 
system  and  the  database  system  which  can  pro¬ 
tect  the  data  against  much  of  the  system* s  own 
software* 
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The  verifiability  of  protection  la  facilitated  b y  the 
logical  and  physical  Isolation  of  protection  mechanisms  froe 
other  mechanisms  in  the  system*  Not  only  are  protection 
mechanlsne  isolated,  but  the  database  access  aechanlsas  also 
are  Isolated  froc  the  user* 

Soae  disadvantages  of  the  proposed  architecture  are  the 
additional  coaaunlcatioo  connections  and  the  overhead  for 
process  interruption  and  synchronization*  Rosever,  with 
laproved  security  and  concurrent  processing,  the  cost  of  the 
additional  coaaunlcatlon  and  processing  overhead  seen*  Just¬ 
ifiable*  This  conclusion  parallels  that  of  the  slallar 
situation  in  OS  kernels.  In  which  added  security  compen¬ 
sates  for  a  small  increase  of  internal  communication* 

In  contrast  to  the  DBC,  which  has  a  highly  developed 
DBMS*  limited  resources  have  forced  MULTISAPE  research  to 
concentrate  on  Just  one  of  the  throe  modulsr— the  PSM*  The 
PSM  design  is  based  on  a  generalized  model  of  database  pro¬ 
tection  fsee  section  3*1*4) «  and  it  employs  multiple  access 
decision  binding  times  { HABTH77 )*  MULTI SAFE  is  an  event- 
driven  data-flow  system*  Thus,  all  processing  is  initiated 
and  controlled  by  events  occurring  within  the  message  flow* 
including  such  events  as  the  transmission  of  data  to  and 
from  the  database*  The  flow  of  messages  in  MULTISAPE  is* 
therefore*  a  critical  factor*  Three  approaches  are  used  to 
study  the  characteristics  of  the  messages*  These  approaches 
Involve  message  structure,  message  classification*  and  mes¬ 
sage  sequences*  Messages  between  modules  are  divided  into 
two  parts:  a  short*  fixed  length  descriptor  and  a  variable 
length  text*  The  message  descriptor  Is  composed  of  three 
parts:  1)  a  message  classification  code*  2)  a  message  ID* 
and  3)  a  message  text  address* 

The  security  of  the  descriptor  is  ensured  by  putting  it 
in  a  "locked  box."  The  descriptor  Is  set  up  as  part  of  an 
abstract  data  type*  Its  contents  are  set  and  checked  by 


protected  procedure*  which  are  Invoked  peraoetrlcelly* 


No 


user  or  user  process  can  directly  access  oessege  descrip¬ 
tors*  The  security  of  the  Message  text  la  ensured  either  by 
POSRing  {depositing  the  text  In  the  receiver'*  Memory)  or  by 
PULLing  (retrieving  the  text  iron  the  sender's  memory) •  For 
example*  all  texts  for  ths  OAK  are  deposited  (PUSHed)  In  the 
Uill's  memory*  because  the  OAM  Is  not  alloved  to  access  the 
memory  of  any  other  modules*  On  the  other  hand*  all  texts 
for  ths  PSM  are  retrieved  (PULLed)  from  the  sender* a  memory t 
because  no  other  modules  can  writs  Into  the  PSM* a  memory* 
The  PUSH/POLL  security  mechanism  is  Implemented  directly  In 
hardware  by  the  private  memory  structure  of  the  system  and 
is  a  key  mechanics  supporting  secure  inter— module  communica¬ 
tion* 


A  message  is  characterised  by  five  attributes*  These 
attributes  are! 

1)  class 

2)  source 

3)  target 

4)  type 

5)  subtype 

Messages  classes  are!  request*  response*  and  status* 
The  message  type  and  subtype  identify  the  functional  context 
of  the  message*  Not  every  combination  of  values  for  these 
attributes  is  allowable  in  MOLT! SAFE.  The  attributes  are 
used  to  establish  a  hierarchy  of  secure  message  classifica¬ 
tions* 


The  set  of  secure  message  sequences  is  partitioned  Into 
four  groupti  for  ident  if  ication— log!  n*  data  (access)*  dis¬ 
play  (of  authorization  information)*  and  change  (of  authori¬ 
zation  information)  subtypes*  Messages,  from  either  author— 
izers  or  users  are  subject  to  two  kinds  of  security 
checking:  1)  checking  specific  to  the  request*  and  2)  sys¬ 
tem  occupancy  checking*  System  occupancy  checks  relate  to 
overall  permission  to  be  an  active  user  of  the  system*  with¬ 
out  regard  to  how  the  system  is  being  used*  The  system 


occupancy  check  is  always  made  in  conjunction  with  login* 
For  example*  the  conditions  (separate  from  user  identifica¬ 
tion)  for  a  given  system  user  nay  be  that  occupancy  is 
allowed  only  between  8:00  a.n»  and  5:00  P*n*  System  occu¬ 
pancy  checking  at  data  request  time  provides  an  (optional) 
additional  binding  time  for  these  conditions* 

Formal  axlons  are  used  to  specify  certain  properties  of 
safe  messge  classifications  and  sequences*  Formal  language 
grammars  are  used  to  describe  acceptable  sequence  struc¬ 
tures*  Under  the  combined  constraints  of  the  axioms  and  the 
grammar  rules*  it  is  possible  to  construct  only  secure  mes¬ 
sage  sequences* 

An  extension  of  Petri  nets  (PETEJ77]  is  being  used  to 
model  dataflow  within  MULTISAFE*  The  aim  is  to  prove  that* 
given  only  valid  message  sequences  in  the  dataflowT  no 
unsafe  state  can  be  reached*  In  addition,  there  are  also 
relationships  between  Petri  nets  and  formal  language  aspects 
of  messge  sequences* 

The  single  "station"  configuration  (one  DAM*  SBM«  and 
PSM)  is  easily  expanded  to  a  distributed  environment*  Sta¬ 
tions  now  communicate  by  interstation  dataflow*  The  system 
remains  secure  if  and  only  if  every  station  appears  (func¬ 
tionally)  as  a  user  to  each  other  station*  This  implies 
that  stations  are  always  connected  UAM  to  DAM*  In  this  way, 
every  request,  whether  arriving  directly  from  a  user  or  by 
way  of  another  station,  requires  an  access  decision  from  the 
PSK  in  the  station  to  which  the  request  is  directed*  Cer¬ 
tain  front-end  message  handling  operations  will  also  require 
an  Interface  between  each  station's  UAM  and  the  rest  of  the 
network*  There  are  some  preliminary  principles  which  are 
currently  under  investigation*  The  principles  are  based  on 
the  assumption  that  data  is  located  at  a  particular  station 
usually  because  it  was  created  or  entered  there*  or  at  least 
because  those  who  will  control  its  use  typically  are  users 
local  to  that  station*  These  principles  are: 
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t)  Authorization  for  acct**  to  data  stored  at  a 
given  station  will  ba  done  at  that  station* 

b)  Enforcement  for  access  to  data  stored  at  a 
given  station  sill  be  done  at  that  station* 

c)  Messages  are  to  be  considered  as  resources* 
like  data*  All  nessags  handling  sill  than  be 
governed  by  access  control  rules*  Both  sending 
and  receiving  of  messages  sill  be  subject  to 
enforcement  checking* 

An  interesting  side  effect  of  this  general  approach  to 
communlcati on  protection  is  that  access  rules  can  now  be 
used  to  impose  user  views  of  tbs  network  configuration* 


5.  ADDITIONAL  ISSUES 


S*i  Networks  and  Distributed  Data 


Computing  la  In  an  early  phase  of  a  strong*  long-term 
trend  toward  networks  and  distributed  databases*  Presently* 
the  Datacomputsr  (Computer  Corporation  of  America)  on  the 
ARPANET  is  one  of  the  few  DBMS  designed  specifically  for 
sharing  in  a  heterogeneous  network*  However*  hardware  and 
software  are  nearly  mature  enough  for  increased  activity  in 
this  area*  and  the  need  to  share  date  already  exists 
(MAKTF78)*  Therefore*  all  approaches  to  future  systems  con¬ 
sidered  by  the  Army  ought  to  take  into  account  the  context 
of  networks  and  distributed  systems*  In  fact*  future  mili¬ 
tary  databases  will  be  distributed*  if  for  no  other  reason 
than  to  reduce  vulnerability  and  enhance  survivability* 
especially  for  applications  such  as  Battlefield  Automated 
Systems* 
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The  separation  of  database  management  functions  Into 
BEC's  Is  a  major  step  toward  meeting  these  nee  requirements. 
Now.  a  database  can  be  shared  by  many  host  computers  without 
regard  to  their  physical  location*  Thus,  In  a  sense  a  net¬ 
work  environment  Is  a  natural  extension  of  multiprocessor 
approaches  to  secure  database  management.  However,  there 
are  additional  problems  (security  and  non— security)  in  net¬ 
works.  A  detailed  investigation  of  these  other  problems  Is 
not  In  the  scope  of  this  report,  but  some  of  the  more  Impor¬ 
tant  points  can  be  mentioned. 

The  National  Bureau  of  Standards  has  been  engaged  In 
exploring  the  issues  and  problems  of  network  operating  sys¬ 
tems  (NOS)  Jointly  with  RADC,  some  results  having  been 
reported  by  Kleibleton  et  al.  In  [K1MBS76,  KIMBS78al.  NOS 
user  and  program  access  controls  are  proposed  at  three  lev¬ 
els!  1)  systems  accss  (occupancy),  2)  file  access,  and  3) 
database  access.  NBS  is  Interested  In  integrated  access 
controls  for  supporting  program  access  to  multiple  remote 
DBMS's,  featuring  a  combination  of  discretionary  and  non— 
dlscret lonary  controls. 

The  subject  of  authorization  and  enforcement  sites 
(distributed  protection)  was  addressed  for  distributed  data 
In  section  4.4.2.  Another  important  extension  to  authori¬ 
zation  which  could  have  great  significance,  especially  In 
military  and  government  networks,  is  N.  Minsky's  concept  of 
cooperative  authorization  {MINSN77].  Important  actions 
often  require  cooperative  authorization!  computer  networks 
provide  Just  the  required  means  for  such  cooperation. 

Networks,  too,  bring  out  the  question  of  the  security 
of  communication  among  nodes.  As  this  problem  is  so  basi¬ 
cally  different  from  Internal  computer  security,  it  will  not 
be  discussed  here  at  all.  NSA* s  COMSEC  group  is  responsible 
for  the  security  of  communications  devices  used  by  the 
government  and  military.  It  is  also  worthwhile  to  note  that 
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It  has  been  shown  that  the  correctness  of  data  communication 
protocols  cannot  be  absolutely  guaranteed  IS0NSC751* 

A  further  problem  of  military  networks*  such  as  AUTODIN 
II*  Is  that  they  will  eliminate  the  possibility  of  having 
only  one  level  of  security  classification  in  a  system  f.t  one 
time*  In  section  2*3*5*  a  near-term  approach  to  connecting 
systems  of  different  levels  has  been  described* 

A  detailed  discussion  of  distributed  system  topologies 
can  be  found  In  1ENSLP77J.  One  configuration*  the  "cluster 
network*"  is  of  special  interest  here*  Beyond  the  ordinary 
communication  among  processors*  high  bandwidth  memory— to- me¬ 
mory  connections  between  processors  form  "clusters*"  There 
are  many  possibilities  for  hardware  implementation  of  nodes* 
Including  functionally  specialized  (DBC)  hardware  and  mini  — 
or  micro— processors*  Mini—  or  micro— processors  can  also  be 
used  as  a  cluster  monitor  for  scheduling  of  workloads  and 
for  file  allocation*  The  MULTISAPE  system  has  basically  a 
cluster  type  of  organization  with  its  interconnected  memo¬ 
ries*  The  addition  to  clusters  of  private  memory  ports  and 
partitioning  of  functions  over  processors  has  proved  to  be  a 
very  worthwhile  approach  to  secure  data  management* 


5*2  Peripheral  Issues 


In  this  section  several  miscellaneous  matters  are  gath¬ 
ered  together  to  be  mentioned  briefly*  More  details  of 
thase*  and  many  other  similar  issues*  are  addressed  in  very 
readable  fashion  In  a  tszt  by  Hoffman  [ HOFFL77 }  and  a  mono¬ 
graph  by  Hsiao*  Kerr*  and  Madnick  [HSIAD78bJ. 
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5.2.1  Abstract  Data  Types 

Abstract  data  types  (ADT)  and  the  concept  of  type 
extension  Is  mentioned  here  because  of  their  Increasing 
Importance  In  high  level  protection  mechanises.  In  very 
simple  terms  an  ADT  Is  a  structured  data  object  type  and  a 
set  of  operations  which  may  be  performed  on  an  object  of 
that  type.  Ko  access  of  any  kind  can  be  made  to  objects  of 
that  type  except  by  calling  one  of  these  predefined  opera¬ 
tions.  Therefore*  ADT's  provide  "pre-packaged"  parametric 
access  to  data.  Higher  level  user  Interfaces  (e.g*.  query 
languages)  are  Inherently  more  secure  than  low  level  ones 
(e.g.*  via  calls  from  programming  languages).  At  loser  lev¬ 
els  (such  as  might  be  used  with  assembly  language  programs) 
the  system's  Internal  operations  are  exposed  ( MANOF75 1 
through  back  doors  and  sneak  paths.  High  level  Interfaces 
to  data  are  an  Important  function  of  ADT's.  They  control 
how  data  Is  used*  even  after  access  control  mechanisms  have 
determined  to  allow  access.  (See  Jones  and  Llskov  [JONEA76* 
JONEA78]  for  a  deter lpt Ion  of  programming  language  exten¬ 
sions  to  Include  ADT's  that  control  which  operations  nay  be 
performed  on  objects.)  In  a  secure  environment*  "naviga¬ 
tion"  of  data  Is  undesirable*  browsing  is  to  be  discouraged. 
ADT's  will  become  a  standard  tool  of  the  secure  system 
designer. 

Several  protection  oriented  concepts  are  related  to 
ADT's.  An  ADT  Is  like  a  ring  of  software  surrounding  its 
object.  Access  to  the  object  can  be  made  only  through  the 
"pre-packaged"  entry  points  '•hlch  are  the  defined  data  oper¬ 
ations.  For  example*  the  rings  of  Muitics  are  a  kind  of 
hardware  implementation  of  ADT's.  Software  in  Its  Inner 
rings  can  do  sensitive  operations  such  as  I/O.  An  outer 
ring  requiring  I/O  must  ask  an  inner  ring  to  do  it  by  a  call 
which  must  go  through  a  pre— defined  gate.  This  Is  exactly 
analogous  to  the  parametric  use  of  ADT  operations.  Having  a 
two  state  ( superv lsor/user )  situation  (as  found  In  OS/J70) 
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1*  1  Ik*  having  only  two  rings*  with  thw  »up»rvUor  cell 
(SVC)  oa  the  gat*.  Thus*  the  eupervieor  end  a  1,1  ot  Itm 
objects  make  up  e  (bloated)  ADT. 

5.2.2  Risk  Assessaent  and  Security  Evaluation 

Security  evaluation  la  the  assessaent  ot  mt feet iveneas 
ot  security  techniques.  Boffsan  has  Isplesantsd  ■  a  systes 
called  SECURATB  [HOFFL78]  to  evaluate  and  analyze  security 
provisions  at  specific  cosputer  Installations.  SECURATB  la 
based  on  a  consideration  of  objects*  threats*  and.  .security 
features*  Using  "fuzzy  setrlcs"  it  helps  deterslne  weak  and 
strong  points  and  facilitates  the  cosparison  of  alternative 
security  designs.  Ratings  are  developed  using  a  .."natural" 
language  Interaction  with  the  user. 

Risk  analysis  (FIPSP74*  COURB75)  is  the  assessaent  of 
threats  to  security*  in  teras  of  liklihood  of  threats  and 
cost  of  losses  due  to  the  aanif estat Ion  of  the  threats.  In 
a  military  envl ronaent  (as  well  as  In  aany  others)*  aetrfes 
for  cost  analysis  of  risk*  threat*  and  protection  are  very 
useful  tools  for  supporting  budget  requests  for  ADP  security 
aeasures.  Risk  aanageasnt  also  eaphaslzes  physical  facility 
protection  and  contingency  planning. 

5.2.3  Auditing 

Auditing  involves  after— the— fact  analysis  and  is 
extreaely  iaportant  to  detecting  systea  flaws  and  penetra¬ 
tions  not  detected  by  the  rest  of  the  security  systea. 
Auditing  has  two  aspects!  the  certification  of  overall  sys— 
tea  security  and  the  analysis  of  transactions  which  have 
taken  place.  The  present  state-of— the— art  of  coaputer 
security  auditing  is  very  far  behind  the  needs.  In  both 
ailltary  and  civilian  envlronaents  aore  qualified  people  and 
more  effective  techniques  are  sorely  needed.  An  NBS  work¬ 
shop  was  held  this  Noveaber*  in  which  auditing  was  tied  in 
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with  secure  data  nanai(«**n t.  Proceedings  should  be  availa¬ 
ble  f roa  Ms.  Celia  Ruthberg  at  NBS. 

5.2.4  Data  Integrity 

Data  Integrity  Is  of  two  kinds:  operational  and  seman¬ 
tic.  Operational  Integrity  implies  <»  consistent  state  of 
the  database  which  Is  achieved  by  synchronizing  concurrent 
accesses  of  multiple  users  to  el ialnate  Interference  between 
read  and  update  operations.  Although  sophisticated  solu¬ 
tions  exist  for  operating  systems.  the  problem  is  more  dif¬ 
ficult  in  a  database  environment.  because  of  the  Increased 
granularity  (GRAYJ75.  RIESD77]  required  and  "phantom"  data 
occurrences  due  to  the  use  of  predicates  to  define  subsets 
of  the  data  [BAYER76].  The  problem  becomes  even  more  diffi¬ 
cult.  as  do  most  timing  problems.  in  networks.  Results 
exist  for  system  level  concurrency  In  distributed  databases 
( ROSED78.  BERNP78  ].  It  would  appear,  however,  that  the  best 
solutions  to  Interlocking  for  concurrency  are  solutions 
which  take  a  global  view  of  the  interaction  of  deadlocks  and 
recovery  as  well  as  concurrency  I STONM78 ).  Crash  recovery 
is  especially  difficult'  in  a  distributed  system. 

Semantic  integrity  (ESWAr75.  HAMMM7S  J  is  a  matter  of 
correctness  of  data  values  and  relationships  in  a  database. 
This  correctness  can  be  protected  to  some  extent  by  user 
supplied  assertions  which  state  constraints  on  the  proper¬ 
ties  of  (values.  ranges  and  data  typesl.  and  relationships 
among,  data  elements.  The  assertions  must  remain  true  after 
Inputs  or  updates  in  order  to  preserve  certain  semantic 
relationships  between  the  existing  data  and  the  incoming 
data.  A  prescribed  action  is  taken  in  case  the  assertion  is 
about  to  be  violated.  (Of  course,  semantic  Integrity  check¬ 
ing  is  limited  to  obvious  errors  and  cannot  detect  subtle 
errors.)  There  is  no  reason  that  semantic  integrity  needs 
to  be  singled  out.  as  It  has  been  in  the  literature.  Integ¬ 
rity  assertions  are  merely  data  dependent  (on  existing  and 


\ 

s* 

Incoming  value*)  iccrai  condition**  and  any  protaction  *y*~ 
tea  bavins  access  condition*  can  handl*  int*srity  const¬ 
raint*  a*  part  of  it*  regular  bu*lno**«  On*  lnt*r**tins 
different  approach  uses  clustering  analyst*  [ LEEKC76  ]  in 
processing  an  exist  ins  databes*  to  detect  data  orror*  and 
even  estimate  value*  for  *i**ins  data* 

S*2*S  Personnel  Problem* 

The  Military  1*  sell  aiart  of  the  importance  of  the 
security  problees  of  personnel  and  the  physical  operating 
environment*  However*  this  report  would  be  incomplete  with¬ 
out  at  least  a  reminder  of  their  signif lcance*  Physical 
access  remains  as  an  overriding  factor  of  system  security* 
Without  protection  of  the  physical  operating  environment 
(computer  operations*  terminals*  removable  media*  etc*)* 
sophisticated  Internal  logical  controls  will  be  only  a  use¬ 
less  expense*  There  is  a  story  that  the  great  wall  of  China 
was  breached  several  times  in  the  first  century  after  It  was 
built — not  with  direct  attacks*  but  it  always  began  with  the 
bribing  of  a  gatekeeper*  There  Is  nor*  computer  abuse  by 
authorized  personnel  than  by  unauthorized  penetrators* 

5.3  Advanced  Issues 

Most  of  the  protection  mechanisms  described  so  far  con¬ 
trol  the  use  of  existing  data*  usually  used  as  inputs  to 
various  programs.  This  is  broadly  true  even  in  cases  where 
access  at  the  user's  level  was  via  a  query  language.  O. 
Denning  ( DENND76*  DENND77a ]  has  gone  beyond  this  by  analyz¬ 
ing  the  flow  of  Information  through  executing  programs*  and 
deriving  the  protection  level  of  program  outputs.  This  work 
addresses  the  question  of  what  level  of  classification  to 
assign  derived  data  in  order  to  protect  information  from 
flowing  from  a  high  security  class  to  a  low  security  class. 
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The  practical  Integration  of  eecuri  Information  flow  Into 
exletlnf  and  proposed  protection  systems  should  bs  a  signi¬ 
ficant  goal  for  the  near  future*  The  security  of  Informa¬ 
tion  flow  should  also  be  extended  to  the  database  environ¬ 
ment*  To  do  so  la  a  general  way  would  need  to  consider 
predicate  (access  condition}  based  discretionary  controls  as 
well  as  the  traditional  hierarchical  levels  of  non— discre¬ 
tionary  military  controls  (l*e**  classification  levels}* 
Rather  than  combining  levels  within  a  lattice*  access  condi¬ 
tions  now  must  be  combined  logically  with  Boolean  operators* 
Perhaps*  It  would  be  most  reasonable  to  implement  secure 
database  information  flow  on  a  higher  level  using  the  con¬ 
cept  of  abstract  data  types*  If  the  exact  effects  (in  terms 
of  Information  flow)  of  each  ACT  operation  were  specified 
and  verified*  calls  to  the  ADT  operations  (and  their  input 
and  output  parameters)  could  be  used  as  the  basic  instruc¬ 
tions  to  analyze  for  flow*  not  tbs  Individual  detailed  pro¬ 
gram  instructions  within  these  routines*  Information  flow 
at  this  high  level  could  achieve  a  savings  in  overhead  with¬ 
out  sacrificing  security* 

In  any  case*  thdre  also  still  remains  a  small  but 
important  class  of  operations  that  do  not  follow  the  star 
property  and  are  not  subject  to  the  same  kind  of  information 
flow  analysis*  These  are  the  operations  which  need  to  write 
from  high  levels  to  objects  of  lowsr  classification  levels* 
An  example  Is  the  "sanitizing"  of  data  in  order  to  lower  its 
classification*  These  operations  are  difficult  to  automate 
and  require  the  system  to  trust  the  user*  They  are*  how¬ 
ever*  becoming  more  and  more  important*  as  increasing  atten¬ 
tion  is  being  given  to  the  problem  of  overclassification* 

In  an  even  more  difficult  class  of  protection  problems 
are  those  dealing  with  unauthorized  information  obtained 
through  Inference  and  deduct  Ion— —statistical  and  otherwise 
( BAUMR74*  DOBKD76*  CONVR76*  KAMJB77*  DAVIQ78).  A  summary  of 
work  In  this  problem  area  and  a  list  of  further  references 
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la  given  by  Denning  (DENND78)*  *ho  conclude*  that  to  ensure 
completely  secure  statistical  databases  would  require  such 
severe  constraints  that  the  utl.lty  of  the  databases  would 
be  seriously  debilitated* 

Mechanisms  for  protection  of  derived  data  are  developed 
by  D*  Cohen  In  (COUED771  and  are  based  on  the  user's  access 
history  as  a  representation  of  the  knowledge  acquired  by  him 
from  the  database* 

Both  information  flow  and  Inference  controls  are  die— 
cussed  In  a  very  readable  style  by  Denning  and  Denning 
( DBNND77bI* 


6*  CONCLUSIONS  AND  fiECOMMENDATIONS 


6*1  Introduction 


The  objectives  of  this  study  called  for  an  investiga¬ 
tion  of  alternative  system  archl tectures  for  secure  DBMS* 
In  reaching  that  objective*  we  have  discussed  backend  compu¬ 
ters*  associative  processors*  database  machines*  networks* 
and  distributed  systems*  as  veil  as  multiprocessor 
approaches*  Ve  have  looked  Into  security  of  operating  sys¬ 
tems  and  weighed  the  advantages  and  problems  of  security 
kernels*  Several  data  security  models  and  experimental  sys¬ 
tems  have  been  reviewed*  representing  non— a rcbl tectural  and 
architectural  approaches  to  non— secure  and  secure  DBMS* 
Conclusions  and  recommendations  have  been  made  along  the  way 
an  the  various  approaches  were  analyzed  and  evaluated*  A 
few  more  suggestions  are  made  In  the  next  section  with 
regard  to  military  security  policy*  The  report  is  then  con— 
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eluded  with  a  summary  list  of  conclusions  and  recommenda¬ 
tions  for  future  research  directions* 


6*2  Modern  Military  Computer  Security  Policies 


One  objective  of  this  study  (see  section  1*1)  Is  to 
help  develop  more  awareness  of  alternatives  to  policies  and 
approaches  which  presently  characterize  defense  oriented 
agencies  dealing  with  computer  security*  It  Is  reasonable 
to  look  to  new  technology  to  improve  the  effectiveness  of 
data  security*  This  report  surveys  many  technical 
approaches  and  solutions*  However*  It  is  a  strong  conclu¬ 
sion  of  this  study  that*  In  addition  to  following  this  tech¬ 
nical  thrust*  It  may  be  equally  useful  for  goverment  and 
military  ADP  operations  to  re— evaluate  their  traditional 
approach  to  protection  policies*  Some  examples  are  sug¬ 
gested  in  this  section* 

The  first  suggestions  are  about  coarse  granularity  and 
hierarchical  security  levels*  These  two  characteristics  of 
modern  military  data  security  policy  combine  to  reduce  the 
effectiveness  of  protection*  Historically*  most  modelling 
and  system  design  of  computer  related  security  (in  the  mili¬ 
tary  world)  has  been  built  around  levels  of  classification* 
a  concept  that  existed  to  suit  a  prior  non— computer  environ¬ 
ment*  Broad*  fixed  security  classifications  were  necessary* 
because  file  drawers  and  other  physical  repositories  of 
documents  each  had  only  one  lock*  If  a  person  had  access  to 
any  documents  in  the  drawer*  he/she  had  access  to  the  whole 
drawer*  The  application  of  these  sane  levels  to  computer 
data*  however*  Is  probably  inappropriate*  The  levels  are 
too  broad  to  effectively  resolve  "need— to— know"  on  an  indi¬ 
vidual  basis  and  the  security  classes  are  most  generally 
applied  to  a  granularity  that  is  too  coarse  (e«g**  at  the 
file  level)**  Furthermore*  policies  based  on  this  hierarchy 
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of  security  levels  have  been  built  deeply  Into  systems*  many 
times  without  an  appreciation  of  alternative  possibilities* 
Policies  to  preserve  the  star  property  ("write  up"  and  "read 
down")  are  examples*  Perhaps  In  a  computer  environment* 
where  finer  granularity  and  more  Individualized  need— to— know 
categories  are  possible*  It  might  be  more  useful  (l*e*«  a 
better  model  of  reality)  to  have  classifications  that  are 
not  necessarily  ordered*  but  which  overlap  arbitrarily* 
With  thessi  there  would  be  no  "up"  or  "down*"  Instead* 
access  privileges  can  be  tailored  to  authorized  access 
needs* 


As  an  example*  there  Is  a  necessity  to  Identify  Intel¬ 
ligence  sources  (MANOF77)*  This  special  need  should  not  be 
lumped  together  with  other  different  needs*  This  require¬ 
ment  Is  not  necessarily  "above"  or  "below"  other  types  of 
requirements  in  a  system!  It  Is  Just  different*  There 
already  are  some  non— hierarchical  categories  within  the  mil¬ 
itary*  such  as  eyes— only*  NATO*  nuclear*  etc. *  but  hierarch¬ 
ical  classifications  are  still  dominant* 

The  effect  of  thw  star  property  and  high  water  mark 
policies  is  a  rising  classification  level  of  files  up  to  the 
highest  level  of  any  item  in  the  file*  The  result  is  an 
over-classification  of*  and  redundancy  of*  vast  amounts  of 
data*  lt*s  reasonable  to  guess  that  a  very  large  percentage 
of  all  military  data  is  overciasslf led*  (Poor  granularity  is 
also  a  cause  of  overclassification — a  granule  must  be  clas¬ 
sified  at  the  highest  level  it  contains*)  As  pointed  out 
strongly  by  G*  Cole  (COLEG78J*  levels  of  authorization  that 
define  a  hierarchy  of  increasing  privileges  are  "not  univer¬ 
sally  accepted  as  being  desirable*"  He  refers  to  Wulf  et 
al*  IW0LFW731  "who  claim  that  'such  structures  are 


*  Even  now*  SDC*  In  a  report  for  DCA* s  CCTC  (p.3—18  of 
( CADYG78  J  I  *  expresses  their  belief  that  file  level  granular¬ 
ity  Is  "state-of— the— art"  and  that  finer  granularity  would 
be  "breaking  new  ground*"  Their  references  for  comparison* 
however*  are  other  military  oriented  projects*  not  the  gen¬ 
eral  database  security  literature*  Their  claim  about 
Increased  complexity  and  performance  cost  to  achieve  finer 
granularity  Is  accurate*  though*  given  present  technology* 
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Inherently  wrong  and  an  at  tha  h»«pt  of  •ocitty'a  cOnctrn 
with  computer  security.'"  Now  ■•chanlaast  with  lesa  caphaala 
on  security  levels  will  bo  needed  to  meet  the  complex  var¬ 
iety  of  requirements  already  existing  In  policies  (e.gM 
access  privileges  varying  depending  on  system  state,  data 
content,  access  history,  statistical  constraints,  informa¬ 
tion  flow)*  It  would  be  natural  to  have  a  mixture  of  clas¬ 
sifications  for  many  records  at  different  levels,  existing 
together  in  the  same  file*  Each  user  would  be  authorized  to 
access  only  an  appropriate  subset.  A  current  direction  of 
Interest  at  the  National  Bureau  of  Standards  Is  In  the  right 
direction— —a  combination  of  discretionary  (granted  rlghtsl 
and  non— discretionary  (labels  and  security  levels)  controls* 
It  will  be  Implemented  at  the  data  element  level,  too,  thus 
addressing  the  companion  problem  of  granularity*  Access 
decisions  will  be  on  a  record— by— record  basis* 

Of  course,  the  present  state— of— the— art  doesn't  reli¬ 
ably  allow  this  kind  of  approach*  That  is  why  there  are 
still  very  few  systems  which  can  process  more  than  one  clas¬ 
sification  level  at  once,  and  those  that  do  are  carefully 
certified  (VALKS771*  Boeever,  the  technical  requirements 
will  be  met  in  time,  and  new  policies  need  to  be  ready* 

A  separate  area  of  concern  about  military  security  pol¬ 
icy  Is  one  which  relates  to  the  notions  of  absolute  and 
relative  security*  Security  guarantees  cannot  be  given  for 
systems  today*  It  is  not  clear  that  they  ever  can  be  given* 
To  be  sure,  improved  technology  and  methodology  has  brought 
us  closer  to  completely  secure  systems*  It  now  appears, 
though,  that  to  get  arbitrarily  close  will  come  at  extremely 
high  cost,  with  ever  more  diminishing  returns*  To  some,  the 
term  "security*  Implies  a  system  level  guarantee  (although 
it  actually  Is  used  within  this  report  to  mean  relative 
security,  not  guaranteed  security)*  One  area  in  which 
security  may  come  close,  but  not  reach  perfection  Is  In 
regard  to  the  notion  of  security  kernels  and  verification  of 
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software  design  ■on-*  implementation  (see  section  2*2)* 
Another  is  protect  •  *>,i  against  inference  in  *  statistical 
database  (see  section  ?•)!• 

One  of  the  significant  questions  under  the  subject  of 
absolute  security  ial  How  important  is  the  conflnesent  prob¬ 
lem  (LAMPB731?  Conflnesent  is  the  prevention  of  inforsatlon 
leaks  through  sneak  paths*  especially  as  caused  by  the  pro¬ 
gram  which  Is  processing  the  sensitive  data*  Confinement 
has  been  a  deep  concern  within  military  oriented  work»  espe¬ 
cially  in  work  concerned  with  guaranteeing  security*  The 
author  believes  that — contrary  to  the  importance  ascribed  to 
It  in  the  literature — conflnesent  Is  no  longer  an  Important 
issue  in  a  realistic  present-day  protection  system*  The 
issue  is(  rather*  data  security*  If  confinement  is  an  over¬ 
whelming  concern*  the  system  design  will  be  inordlnantly 
constrained*  Overt  channels*  such  as  shared  files*  can  be 
closed  off  by  making  the  procedures  in  question  memoryless* 
Most  covert  channels  and  Trojan  horses  can  be  ferreted  out 
by  kernel izat ion  and  software  verification*  Perhaps  we  may 
have  to  endure  the  remaining  low  bandwidth  channels*  if  any* 
as  part  of  tbe  cost  of  doing  business*  Kimble ton  [KIMBS78bl 
has  suggested  that  a  sensitivity  analysis  might  be  helpful 
for  a  given  system*  in  showing  how  far  it  is  cost  effective 
to  go  toward  absolute  security* 

An  additional  subject*  toward  which  a  new  viewpoint 
might  benefit  both  military  people  and  others  Interested  in 
security*  is  that  of  performance  overhead  I  see  (HARTH77})* 
With  any  function  that  does  not  contribute  directly  to  the 
users*  access  of  resources*  there  is  associated  the  "neces¬ 
sary  evil"  of  an  overhead  cost  in  storage*  processing*  and 
I/O*  The  distinction  between  the  usage  of  resources  consid¬ 
ered  to  be  directly  serving  the  user  and  that  considered  to 
be  overhead  la  not  always  a  clear  one*  The  actual  ml nl mum 
software  required  to  access  a  record  of  data  is  relatively 
small*  However*  if  the  addition  of  software  for  the  operat— 
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lng  syateni  virtual  machine  emulation*  access  aethodst  the 
use  of  higher  level  languages*  backup  and  recovery*  file 
management*  etc.  are  considered  to  be  only  "conveniences)11 
then  the  resource  usage  claimed  by  overhead  approaches  100%. 
As  the  cost  of  personnel  and  software  is  increasing  and  the 
cost  of  computing  power  Is  decreasing*  one  can  conclude  that 
to  use  computers  to  automate  as  many  of  these  functions  as 
possible  Is  economically  sound — not  to  mention  greatly  more 
reliable.  This  Is  especially  true  In  the  military  environ¬ 
ment  where  100%  redundancy  (of  hardware*  software*  and  per¬ 
sonnel)  Is  not  an  unheard  of  commitment  to  achieve  security 
for  different  classification  levels.  It  Is  likely  that  pro¬ 
tection  will  soon  be  considered  as  an  Integral  part  of  the 
system  (with  respect  to  performance)  and  not  an  add-on  over¬ 
head. 

6.3  Summary  of  Conclusions  and  Recommendations 

This  section  recapitulates  the  important  points  end 
conclusions  of  this  study*  beginning  with  a  couple  of  gen¬ 
eral  observations  made  during  the  course  of  the  study! 

1)  A  large  variety  of  policies*  mechanisms*  approaches*  and 
system  views  were  encountered  among  organizations  repre¬ 
senting  commercial  software  contractors*  Internal  mili¬ 
tary  development*  industrial  research  and  development* 
and  academic  research.  This  variety  makes  It  clear  that 
the  subject  area  Is  still  very  much  developing;  there  are 
still  more  questions  than  answers — especially  answers 
with  proven  effectiveness  and  practicality. 

2)  There  Is  a  large  amount  of  money  and  effort  Invested  In 
current  operating  systems  and  database  systems*  including 
their  protection  subsystems*  The  Inertia  of  this  mass 
dictates  that  developsent  In  the  area  of  data  security 
will  be  evolutionary  and  not  revolutionary. 
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The  following  conclusions  Indicate  recommended  future 
technical  directions  in  which  the  author  believes  research 
funds  way  aost  profitably  be  expended* 

1)  Arch 1  tec tural  and  systems  approaches  t£  database  securi¬ 

ty —  Alaost  ail  CPU's  tottny  are  designed  for  nuaerlc  pro¬ 
cessing*  Database  and  database  security  applications 

need  different  functions*  Specialized  hardware  is  becom¬ 
ing  economically  feasible  and  Is  highly  suited  for  data¬ 
base  and  database  security  applications*  Architectural 
building  blocks  abound — in  multiprocessor  conf lgurat ions* 
associative  hardware*  block  oriented  random  access  memo¬ 
ries*  minicomputers*  microprocessors*  and  intelligent 
terminals*  The  approach  is  attractive  to  security  appli¬ 
cations  because  of  its  isolation  of  functions  and  the 
help  that  modularity  gives  to  system  verification*  The 
lead  quotation  in  a  paper  on  computer  system  organization 
in  the  1980's  [APFEH78]  is!  "Soon*  system  architects  will 
treat  all  system  components hardware  as  well  as  soft¬ 
ware*  user  interfaces  as  well  as  databases as  structural 

or  architectural  elements*" 

2)  Pi strlbuted  databases  and  networks — This  is  the  future* 
especially  the  future  of  military  data  systems*  The  army 
must  plan  now*  in  order  to  be  there*  The  archl tecturel 
approach  fits  in  very  well  here*  too* 

3)  Broader  approach  to  authorization — The  Army  (and  all  mil¬ 
itary  systems)  needs  to  go  beyond  present  policies  in 
order  to  get  away  from  hierarchical  levels  of  security 
classification*  These  levels  are  the  cause  of  many  prob¬ 
lems*  not  the  least  of  which  is  extreme  overclassl f lea— 
tlon*  Decentralized  authorization*  dircret lonary  con¬ 
trols*  dynamic  (on-line)  authorization  changes*  and 
protection  languages  for  Improved  interfaces  to  authorlz— 
ers  are  all  part  of  the  new  approach  to  authorization* 

6)  Precision  and  flexibility  of  enf orcesent — New  security 
requirements*  such  as  improved  auditability  and  legis¬ 
lated  privacy  protection  will  require  finer  granularity* 
partial  enforcement  capability*  and  access  decision 


61 


dependency  on  a  large  number  of  system  variables  (data 
dependency!  time  of  dayf  terminal  Identification!  etc. I. 

5 )  integrat Ion  of  opera  ting  ays  t  en  and  databaae 

funct lone*- The  close  relationship  among  OS  and  DBMS 
functions  dictates  thlsy  for  both  performance  and  secur¬ 
ity  reasons!  much  work  remains  to  be  done  toward  this 
goal.  The  days  of  operating  systems  with  Just  file  han¬ 
dling  are  numbered.  Every  OS  will  have  a  DBMS.  Concepts 
such  as  "database  operating  systems"  and  "database  access 
methods"  for  OS  are  already  developing. 

6)  Software  kerne  1  met  hodo 1 oev - To  meet  the  profound  need 

for  increased  confidence  in  kernel  techniques!  more  work 
is  required  In  the  areas  of  kernel  specification!  verifi¬ 
cation!  faithful  implementation!  and  testing.  Perhaps! 
the  most  Important  problem  (and  one  not  receiving  the 
most  attention)  is  that  of  the  partitioning  of  kernel  and 
non— kernel  functions!  l.e»!  dealing  with  the  "spaghetti 
bowl"  syndrome.  More  treatment  is  also  needed  with  the 
secure  handling  of  resulting  non— kernel  trusted  software. 

71  Addlt  tonal  protection  mechanisms - Beyond  mechanisms  for 

directly  controlling  access!  there  is  an  increasing  need 
to  automate  reliably  functions  such  as  audit  trails!  mon¬ 
itoring!  surveillance!  and  exception  reporting*  The 
WASSO  terminal  is  a  beginning. 

81  Mul t lple  leve Is  of  data  in  the  same  system — This  should 
be  an  Immediate  goalv  and  many  other  recommendations  made 
in  this  report  (such  as  the  suggested  changes  in  security 
policy)  will  contribute  to  its  achievement.  Howeverf  of 
course!  appropriate  hardware  and  software  technology  to 
support  thiB  requirement  is  not  quite  yet  generally 
available.  < 

9)  Mil itary  privacy — Military  ADP  installations  will  have  an 
increasing  need  to  protect  privacy  (as  well  as  security). 
For  example!  privacy  protection  requirements  for  such 
functions  as  personnel  and  payroll  under  the  Army  Stan¬ 
dard  Systems  have  been  the  subject  of  much  recent  legib¬ 
le  t  ion. 
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10)  Advanced  nrob I ems —  Hope  for  future  solution*  to  the  more 
difficult  problems  (such  as  control  of  information  floe 
or  inferential  extraction  of  database  Information)  must 
be  based  on  increased  support  to  present  research  In 
these  areas*  Personnel  identification  1*  another  diffi¬ 
cult  problem  that  must  be  solved  as  an  artificial  intel¬ 
ligence  or  pattern  recognition  problem* 

111  The  role  of  the  Army  1 n  database  secur 1 ty — There  are 
several  general  ways  In  which  the  Army  can  Increase  Its 
role  In  the  advancement  of  the  state-of-the-art  In  data¬ 
base  security* 

a)  Broader  Interest  in  database  security  itself — The 

treatment  of  database  security  in  existing  ADP  secur¬ 
ity  regulations  (e*g«*  { AKMYK77 ) )  Is  relatively 
sparse*  This  lsf  of  course*  partly  due  to  the  fact 
that  the  necessary  technology  has  not  arrived*  This 

study  itself  is  evidence  of  the  fact  that  Interest  is 
Increasing* 

b)  Increased  participation  and  involvement— An  example 
of  such  Involvement  Is  the  U. S*  Army  Automation 
Securl ty  Workshop*  11—12  December  1978*  in  Leesburg* 
Virginia.  This • workshop  is  supported  by  A1RMICS  and 
funded  by  the  USACSC  ISBAD  program.  The  workshop 
will  bring  about  communication  between  researchers 
and  prac t 1 t loners  in  the  area*  as  well  as  with  users 
and  management  types*  It  also  will  serve  to  generate 
some  new  ideas  and  help  to  put  existing  methodology 
In  perspective*  The  Army*s  participation  in  the  KSOS 
project  is  another  example  of  how  the  Army  Is  already 
expanding  Its  role* 

c|  More  sponsored  research  in  computer  securl ty—— This 
is*  perhaps*  an  area  in  which  the  Army  needs  to 
increase  its  commitment,  if  it  seriously  desires  to 
be  a  significant  force  (along  with  the  Navy  and  Air 
Force*  who  are  already  established  in  the  area)  in 
shaping  the  future  state-of-the-art*  In  this  regard* 
there  seems  to  be  a  slight  trend  toward  a  lessening 
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of  Navy  and  Air  Force  spending  on 
tectlon.  In  arfdl t lon(  there  seem6  to  he  a  move  in 
Air  Force  emphasis  toward  prototype  demonstrations. 
Also,  sponsored  research  must  not  all  be  heavily  mis¬ 
sion  oriented,  either.  Some  latitude  for  experimen¬ 
tation  with  different  ideas  and  directions  Is  neces¬ 
sary  to  s  ->  r  v  e  the  longer  term  future. 
d|  Communication  with  the  other  branches — The  service 
brancltes  have  been  competing,  rather  than  communicat¬ 
ing  and  cooperating  In  their  ASP  security  efforts. 
Each  one  has,  to  some  extent,  developed  a  program 
that  Independently  parallels  the  others.  Each 

appears  to  be  solving  problems  without  sharing  the 
solutions.  The  result  Is  a  waste  of  effort  and 

resources,  reinventlon  of  concepts,  and  a  hindrance 
to  future  Interoperability.  In  fact,  the  future 
requirements  for  interoperability  could  conceivably 
transcend  the  various  service  branches  and  extend  to 
cooperative  systems  among  NATO  countries.  The  army 
presently  has  an  opportunity  to  be  a  moving  force  in 
bringing  the  various  groups  together.  Perhaps,  the 
DoD  Consortium  can  be  instrumental  In  Implementing  an 
amalgamation  of  effort  and  results, 
e)  Avoid  confusion  of  research  with  development  and 
Implementation — By  and  large,  the  resources  available 
at  universities  are  limited  to  conceptual  research 
and  very  early  stage  bread— board  prototypes.  In  most 
universities  the  emphasis  Is  heavily  toward  the 
former.  As  a  rule,  an  academic  department  cannot 
afford  to  commit  large  amounts  of  resources  and  per¬ 
sonnel  to  producing  working  systems.  (Perhaps  Kansas 
State  University  and  Its  work  on  the  back-end  compu¬ 
ter  was  a  notable  exception.)  Academics  can  best 
contribute  In  very  early  stages  with  concepts,  ideas, 
directions,  and  possibly  high  level  designs.  Soft¬ 
ware  firms  can  then  do  a  better  Job  at  serious  Imple¬ 
ment  a  1 1 on. 
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